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
- 1.
generate-jobs
: Generate Helm upgrade jobs - 2.
upgrade-support-and-staging
: Upgrade support and staging hub Helm charts on clusters that require it - 3.
filter-generate-jobs
: Filter out jobs for clusters whose support/staging job failed - 4.
upgrade-prod-hubs
: Upgrade Helm chart for production hubs in parallel - Known issues with this workflow
- Posting the deployment plan as a comment on a Pull Request
- 1.
- Automatically bumping image tags and 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 UI filtered for the deploy-hubs.yaml
workflow (described above) running on the default branch.
Hence, it should be much easier to find the current deployments happening on master
than just following GitHub’s UI.