Our CI/CD system#


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.

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.