How we set up automated checks for our GitHub projects
Every official team project should be set up to require a number of checks to pass before a pull request can be merged.
Prefer GitHub workflows
These check should be written as GitHub workflows if possible. If GitHub workflows aren’t fit-for-purpose, our next choice should be Circle CI, and only for the specific checks that can’t be configured as GitHub workflows.
ⓘ At the time of writing, the chief reason to create a check in Circle CI rather than GitHub workflows is because you need to run checks against forked branches that need secrets - e.g. Percy checks. GitHub workflows don’t currently support this.
What to check on pull requests
All the GitHub workflows that are run on pull requests should be kept in a file called
All website projects should run as many of the following checks as make sense:
run-image: Build the docker image from the
Dockerfileand check it successfully runs the website
run-dotrun: Check the
dotruncommand (the dotrun snap) runs the development server successfully
.scssfiles conform to our formatting standards
.jsfiles conform to our formatting standards
.pyfiles conform to our formatting standards
test-python: Run any Python tests and upload code coverage to codecov.io
ⓘ For example, kuberflow-news.com
Running checks against master
We may also want to run some checks against the master branch to check the integrity of the codebase. An example of this might be using
linkchecker to check internal links, or Cypress to check forms. These could either be run whenever something is merged into
master, or on a schedule.
ⓘ For example, Cypress checks on ubuntu.com