Automated checks

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 pr.yaml.

All website projects should run as many of the following checks as make sense:

  • run-image: Build the docker image from the Dockerfile and check it successfully runs the website

  • run-dotrun: Check the dotrun command (the dotrun snap) runs the development server successfully

  • lint-scss: Check .scss files conform to our formatting standards

  • lint-js: Check .js files conform to our formatting standards

  • lint-python: Check .py files conform to our formatting standards

  • test-js: Run JavaScript tests and upload code coverage to codecov.io

  • test-python: Run any Python tests and upload code coverage to codecov.io

  • inclusive-naming-check: Check changes within the PR for non-inclusive language

For example, kuberflow-news.com

Running checks against main

We may also want to run some checks against the main 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 main, or on a schedule.

For example, Cypress checks on ubuntu.com

Last updated 1 year, 9 months ago.

Help improve this document in the forum.