Skip to content

Latest commit

 

History

History
113 lines (78 loc) · 3.42 KB

DEVELOPERS.md

File metadata and controls

113 lines (78 loc) · 3.42 KB

Notes for developers

System requirements

just

just is a handy way to save and run project-specific commands. It's unrelated to the package with the same name on PyPI.

# macOS
brew install just

# Linux
# Install from https://github.com/casey/just/releases

# Show all available commands
just # Shortcut for just --list

Development

Set up a local development environment with

just devenv

and create a new branch. Then, iteratively:

  • Make changes to the code

  • Run the tests with

    just test

  • Check the code for issues with

    just check

  • Fix any issues with

    just fix

  • Commit the changes

Finally, push the branch to GitHub and open a pull request against the main branch.

Environments

A reusable action is run within a container, which is created from a image, which in turn is created from a repository. As this is a Python reusable action, it is run within a Python container, which is created from a Python image, which in turn is created from the opensafely-core/python-docker repository.

The Python container provides the reusable action with its production environment. From a developer's perspective, the most important characteristic of the production environment is that it contains Python 3.8. The next most important characteristic is that it contains the versions of the packages listed in requirements.txt from the opensafely-core/python-docker repository.

Notice, however, that there are two sets of requirements files within this reusable action's repository:

  • The versions of the packages listed in requirements.prod.in are for local development and should mirror the production environment. In other words, the versions of the packages listed in requirements.prod.in should mirror the versions of the packages listed in requirements.txt from the opensafely-core/python-docker repository.

  • The versions of the packages listed in requirements.dev.in are for local development and need not mirror the production environment.

Tagging a new version

This reusable action follows Semantic Versioning, v2.0.0.

A new patch version is automatically tagged when a group of commits is pushed to the main branch; for example, when a group that comprises a pull request is merged. Alternatively, a new patch version is tagged for each commit in the group that has a message title prefixed with fix. For example, a commit with the following message title would tag a new patch version when it is pushed to the main branch:

fix: a bug fix

A new minor version is tagged for each commit in the group that has a message title prefixed with feat. For example, a commit with the following message title would tag a new minor version when it is pushed to the main branch:

feat: a new feature

A new major version is tagged for each commit in the group that has BREAKING CHANGE in its message body. For example, a commit with the following message body would tag a new major version:

Remove a function

BREAKING CHANGE: Removing a function is not backwards-compatible.

Whilst there are other prefixes besides fix and feat, they do not tag new versions.