Defining workflow using Github Actions — Part 1

Photo by Pietro Mattia on Unsplash

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 of GITHUB_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.

• https://github.com/marketplace/actions/s3-sync
• https://github.com/marketplace/actions/upload-s3

We will require the AWS access and secret key with putObject permission to the deployment bucket.

1. Go to settings tab for repo. (Only visible for person with admin access)
2. Go to Secrets in left navigation bar
3. Add New secret by mentioning the variable names as shown below. These names are going to be referred in Actions YAML.
4. Once we commit all the files along with workflow YAML, we can check the status of task in Actions tab.

Adding secrets in Github

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.