CI/CD
Overview
Concurrent tagging
We need to avoid the CI workflow running concurrently as the tagging process generates a commit to the repository. We prevent this by running a pre-push hook on main which will check to see if the CI workflow is running and block the push is if it is.
We also check the CI workflow status in the pnpm run tag script and prevent tagging if the workflow is running. This should prevent workflow failures due to the previous workflow pushing a commit.
This also means if you are ready to commit to main and the CI is currently running you will need to wait for it to complete so you can include the automated commit in your push.
If you have already merged commits to main the easiest way to resolve this is to create a branch from main, delete your local main branch, wait for the CI to complete, checkout main again and fast forward merge your commits from the temporary branch.
These commands will achieve this, assuming you are on main...
git checkout -b temp
git branch --delete main
// wait for CI to finish
git checkout main
git merge temp --ff-only
git branch --delete temp
git push origin/main
You can run the CI check yourself at any time with the following command
pnpm run ci
Rebase and fast forward merge
Merge commits to main branch are blocked, there is no reason to perform any standard merges which creates a merge commit if we follow the the process described above.
GitHub has no way of enforcing fast-forward merges on a given branch, but we can enforce this locally. Please add the following config to the .git/config file in your local repository
[branch "main"]
mergeOptions = --ff-only
Deployment users & roles
The deployment user and roles needed in our pipelines have been created via the CLI using SAM bootstrap. It bootstraps these users and roles following the best practice of least privilege.
The diagram below illustrates it. We have a single deployment user with IAM access key. It then assumes a pipeline execution role for any AWS access needed during the run of a deployment. Similarly, a role is assumed for the actual cloudformation deployment.
Having a single deployment user, means we don't grant access keys to Github actions for the production account, instead they assume access to production for a short while (and we can control that session time), and we can tie down the permission set of the role they assume as much as we want.
The IAM user and all roles used for the deployments can be found in the last pass note Encryption Hectare under the CI/CD GITHUB ACTION section.
Resources: