Defining workflow using Github Actions — Part 1
Github Actions bring a fine grain control over our CI/CD tasks. The power can be realised while working on complex repo and deployment setup. So, defining a workflow is essential in any repository to have a formalised way of taking the code to production. It can vary from working directly onmaster
branch, to having a sophisticated pipeline of review, QA, staging and production. We can even support multiple projects from same repo. But all this requires a governance model to avoid chaos. Some of them can be like:
- Restricting the branches which can raise Pull Request to main branch
- Defining a main branch (default: master)
- Pipeline defining which branch is allowed to raise PR to which other branch.
- Allowing merge only in case of approval
- Triggering deployment after
n
number of approvals etc
Restricting branches which can raise PR to main branch
We can add many steps
. But before running any CI/CD tasks if we do preliminary checks like this, it will save a lot of compute power — fail fast
and avoid unnecessary job queuing. We can even simplify this by writing a javascript
based Actions
of our own and using it here. But for now, we stick to bash
scripting:
- name: Branch checks
run: |
if [[ ! ( \
"$GITHUB_HEAD_REF" == "development" \
&& "$GITHUB_BASE_REF" == "master"
) ]]; then
exit 2
fi
We are just failing the job if the PR is not raised from development
branch to master
branch. Here, the global variables defined by Actions are:
GITHUB_HEAD_REF
refers to branch from which we are raising the PR and it should always be ahead ofGITHUB_BASE_REF
GITHUB_BASE_REF
refers to branch to which the PR is raise. Once changes are merged to this branch, it will trigger the CI/CD tasks.
Manual deploy to S3
There are many Actions
available to deploy the code to S3, but we will try to write a step
to upload it on our own.
We will require the AWS access and secret key with putObject
permission to the deployment bucket.
- Go to settings tab for repo. (Only visible for person with admin access)
- Go to Secrets in left navigation bar
- Add
New secret
by mentioning the variable names as shown below. These names are going to be referred inActions
YAML. - Once we commit all the files along with workflow YAML, we can check the status of task in
Actions
tab.
We need to install AWS CLI in task runner machine. We can do it either manually using pip install
or can use Actions
from Marketplace
.
- name: AWS CLI
uses: chrislennon/action-aws-cli@v1.1
After adding that, we are ready to upload to S3 using CLI:
- name: Upload
run: |
aws configure<<EOF
${{ secrets.AWS_ACCESS_KEY_ID }}
${{ secrets.AWS_SECRET_ACCESS_KEY }}
us-east-1
json
EOF
aws s3 sync ./build ${DEPLOY_PATH}
env:
S3_DEPLOY_PATH: s3://production-bucket/deploy_path
(Here, we are hardcoding few assumptions like region
and format
)
For full YAML config, please check https://github.com/itzsrikanth/github-actions-recipes/blob/master/branch-check-s3-upload.yaml
Catch Part-2 here and stay tuned for other Github Actions recipes.