Skip to content

Continuous Integration

Jobbergate employs GitHub actions for its continuous integration processes. Detailed descriptions of these actions are provided on this page.

Automated Quality Assurance

Jobbergate's git repository incorporates a GitHub Action, specified in test_on_push.yaml, which is designed to execute our quality assurance tools across all Jobbergate sub-projects simultaneously. The action is activated anytime a new commit is pushed to the main branch or whenever a pull request is submitted.

The suite of quality assurance tools encompasses unit tests, code coverage, linters, code formatters, and static type checkers. Comprehensive documentation about each tool is available in the Quality Assurance Tools section.

Automated Publication to PyPI

The major components of Jobbergate are published on PyPI, the Python Package Index. They are available at:

These packages are automatically published to PyPI by three linked GitHub Actions that are detailed below.

Prepare for release

The first action involved in publication is the prepare_release.yaml) action. It is triggered manually on github through a "workflow dispatch event" whenever new features or fixes need to be published.

The action takes two arguments that must be supplied by the user. They are:

  • Use workflow from: The branch from which the release will be created. The default is main, and it's highly recommended that releases are cut from this branch in order to keep a linear commit history between releases and pre-releases.
  • Release Type: This will describe the release type that will be created. Because Jobbergate uses semantic versioning, it's important to carefully select the correct type of release. For mor information on release types, please see the Poetry documentation to learn more.

Once activated, this action:

  • Uses Poetry to bump the version number of all the Jobbergate sub-packages according to the release type selected.
  • Checks if the new version number is synchronized between the sub-packages, and fails if they are not.
  • Creates a new dated entry for the new release on each of the sub-packages' changelog files from the contents of the "Unreleased" section.
  • Creates a new branch named prepare-release/<version>.
  • Opens a draft pull request titled Release <version>.

In this way, all the changes above can be reviewed before the release is published, and all quality assurance tests are executed for the pull request.

The remaining steps of the workflow are chained automatically once the PR is accepted and merged into main.

Create a new tag

The next action in the sequence is the tag_on_merged_pull_request.yaml action. Once the automatically created release PR is merged into the main branch, this action is triggered. It creates and pushes a new git tag to GitHub. The tag is based on the new version number for the release.

Publish on Tag

The final action is publish_on_tag.yaml This action is triggered when a new version tag is pushed to the repository. It first double checks if the tag matches the version number of each Jobbergate component, and then it builds and publishes the packages on PyPI.