Our CI/CD system

Overview

We use GitHub Actions as our CI/CD vendor and all our workflows are defined as YAML files in the .github/workflows folder in the infrastructure repo.

Longer or more complex workflows are discussed on their own pages (listed in the table of contents), whereas you can find descriptions of simpler or shorter workflows further down this page.

• Automatic hub deployment
  • Main hub deployment workflow
  • Posting the deployment plan as a comment on a Pull Request
• Automatically bumping image tags and helm sub-chart versions
  • Bumping image tags
  • Bumping helm sub-chart versions

Helm chart values and cluster config validation

All of our helm charts have associated values.schema.yaml files and we also maintain a custom cluster.schema.yaml file. Here is an example of a values.schema.yaml file from the basehub chart. These schemas explicitly list what values can be passed through our config, and what type these values should have. Therefore, we can use these schemas to validate all our config before making deploys, and catch bugs early.

We have functions within the deployer that validate the cluster config, the support chart values, and the helm chart values for each hub against these schemas. We automatically run these functions in GitHub Actions configured by the validate-clusters.yaml workflow file. This workflow is only triggered when related configuration has changed.

Finding the right workflow runs

GitHub’s UI is slightly confusing for distinguishing between workflows that ran on a Pull Request and workflows that ran on the merge commit to the default branch.

To help contributors to our infrastructure repository find the right workflow run, we have a GitHub Actions workflow that posts a comment on a just merged Pull Request with a link to the GitHub Actions run of the deploy-hubs.yaml workflow (described in Automatic hub deployment) that the merge triggered. Hence, it should be much easier to find the current deployments caused by merges than just following GitHub’s UI.

Required workflows and author auto-assignment

To make the most out of the Project Boards that 2i2c uses, the auto-author-assign-pull-request.yaml workflow automatically assigns authors to Pull Requests.

Because this is a practice that we wish to have across other 2i2c repositories, an equivalent of the auto-author-assign-pull-request.yaml workflow in 2i2c-org/infrastructure exists in 2i2c-org/.github. The workflow in the 2i2c-org/.github repository is marked as a required workflow. This means that it will run on every PR in the repositories that it’s setup as required for.

Note

An additional, slightly different workflow than the one in 2i2c-org/infrastructure is set up in the 2i2c-org/.github repository because we want to avoid adding up to GitHub’s API rate limits for 2i2c-org/infrastructure.

Hence, the workflow in 2i2c-org/infrastructure, will only trigger when PRs are opened/reopened instead of every time they are updated.

This is because a GitHub Required Workflow is expected to successfully run for each commit in that Pull Request, otherwise merging it will be blocked.