GitHub Actions

What we use GitHub Actions for

We use Github Actions for pre-merge checks, creating releases after merge (except repos using the Jenkins tag-* jobs), and publishing releases on package repositories.

Pre-merge checks

Digital Marketplace repositories should have automated tests that can be run to ensure that code works as expected. To make it less likely that changes will be merged that break these tests, we have required GitHub checks that check the tests pass before allowing a pull request to be merged. This is configured by adding a GitHub Actions workflow to each repository.

For simple Python based repositories we have a workflow template Digital Marketplace Python CI workflow template. GitHub Docs has guidance on how to use a workflow template. For more complicated repositories including NodeJS and/or service dependencies you can look at the supplier frontend test workflow or the api app test workflow as examples.

Publishing libraries

We publish almost all Digital Marketplace shared repositories to package repositories:

• the release workflow is triggered when a merge is made to the default branch. It checks whether the package version number has been changed, and if so it creates a new GitHub release (and git tag) with that version number

• the publish workflow is triggered when a new GitHub release is made (whether by the release workflow or not). It creates an archive of the tag contents and adds it to the appropriate package repository

Together these two workflows work to create and publish package releases with minimal developer intervention; all that is needed is for the version number to be updated. Dependabot then takes care of ensuring that consumers of the library get the update.

The exceptions are:

1. govuk-frontend-jinja, which uses git references. We can’t publish it to pypi.org because Land Registry already published a package with that name.

2. Some repositories still use the Jenkins tag-* jobs instead of the release workflow.

Setting up repo for release and publish workflows

Python

1. Create PyPI project by manually uploading distribution archives to PyPI using Twine

2. Create PyPI token for project

3. Copy Jenkins GitHub token from jenkins_env_variables.GITHUB_ACCESS_TOKEN

4. Following the steps on creating encrypted secrets for a repository, add the following secrets to the repository:

• PyPI token as PYPI_TOKEN

• Jenkins GitHub token as DM_GITHUB_TOKEN [1]

4. Copy the release.yml and publish.yml workflows from digitalmarketplace-test-utils/.github/workflows.

Node

1. Copy Jenkins GitHub token from jenkins_env_variables.GITHUB_ACCESS_TOKEN

2. Following the steps on creating encrypted secrets for a repository, add the following secrets to the repository:

• NPM token as NPM_TOKEN

• Jenkins GitHub token as DM_GITHUB_TOKEN [1]

3. In package.json ensure that any private: true decalaration has been removed as this will prevent publishing on NPM.

3. Copy the release.yml and publish_package.yml workflows from digitalmarketplace-frameworks/.github/workflows.

[1] (1,2)

DM_GITHUB_TOKEN is required because we want the release workflow to trigger the publish workflow, but releases made with the repository GITHUB_TOKEN do not trigger workflows. See Crown-Commercial-Service/digitalmarketplace-test-utils#41 for more details.