Skip to main content

.github/workflows/deploy.yaml

Overview

When a deployment is initiated, two configuration files are automatically generated. They are the:

  • .art/art.yaml
  • .github/workflows/argonaut-<envname>-<appname>-deploy.yaml

This section provides a breakdown of the .github/workflows/argonaut-<envname>-<appname>-deploy.yaml file and explains the functioning.

File breakdown

This file is triggered on two possible occasions:

  • When a push is made to the main branch of your repository or
  • When you tag your commit with something like v1.0.4. i.e only specific versions are deployed, instead of every push updating the Docker hub.

The github/workflows hold the files that configure Github actions. The workflow runs two jobs:

  1. The build job
  2. The deploy job

Each job is a set of steps that execute on the same runner. A step is either a shell script that will be executed or an action that will be run.

A runner is a server that runs your workflow when they are triggered.

Build job

repo/.github/workflows/appName-build.yaml
jobs:
build:
environment:
name: violet

runs-on: ubuntu-latest
name: Build and Push Img
steps:
- name: Get the version
id: get_version
run: echo ::set-output name=VERSION::${GITHUB_REF#refs/tags/}
- name: Fetch repo
uses: actions/checkout@v2
- name: Get Short SHA
id: get_sha
run: echo ::set-output name=SHA_SHORT::$(git rev-parse --short HEAD)
- name: Set up QEMU
uses: docker/setup-qemu-action@v1
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
- name: Build Image
uses: docker/build-push-action@v2
id: build
with:
context: .
file: ./Dockerfile
push: false
tags: ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/argonaut/ghosh:${{ steps.get_sha.outputs.SHA_SHORT }}

outputs: type=docker,dest=image.tar

- name: Push to ecr
uses: argonautdev/aws-ecr-action@v4.1
id: push_to_ecr
with:
access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID }}
secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
account_id: ${{ secrets.AWS_ACCOUNT_ID }}
repo: argonaut/ghosh
region: us-east-1
tags: ${{ steps.get_sha.outputs.SHA_SHORT }}
create_repo: true
image_scanning_configuration: true
docker_image_path: image.tar

The build job, as its name suggests, is responsible for building the application. The job is executed in the following steps;

  1. Get the version

This step is executed in order to get the name of the current tag that is being built and then save it in the VERSION variable.

  1. Fetch repo

This action checks out to your repository under $GITHUB_WORKSPACE, so your workflow can access it. By default, only the commit for the ref/SHA that triggered the workflow is fetched.

  1. Get short SHA

This step gets the shorter unique SHA for the current commit (HEAD) and then saves the result in the SHA_SHORT variable. This is the unique hexadecimal number that identifies your commit.

  1. Set up QEMU

QEMU is a machine emulator that can run operating systems and programs for one machine on a different machine. This action installs QEMU static binaries which are used to run builders for architectures other than the host.

  1. Set up Docker Buildx

This action configures buildx, which is a docker plugin that provides enhanced build capabilities.

  1. Build image

This step is executed basically to build the docker image at the docker file's relative path, provided during the app service configuration.

The push property is set to false by default, indicating to the build not to automatically push the image. The export action for the build result is then set with the outputs property.

By default, the export type is docker. This writes the single platform result image as a docker image specification tarball on the client; hence the .tar image extension. Read more about docker buildx build here.

  1. Push to ecr

Finally, the last step in the build job is to push the created docker image into Amazon Elastic Container Registry (ECR). This requires some already provided and configured parameters.

Deploy job

repo/.github/workflows/appName-deploy.yaml
deploy:
environment:
name: violet

runs-on: ubuntu-latest
name: Deploy to Argonaut
needs: build
steps:
- name: Fetch repo
uses: actions/checkout@v2
- name: Get Short SHA
id: get_sha
run: echo ::set-output name=SHA_SHORT::$(git rev-parse --short HEAD)
- name: Download art
run: curl --silent https://github.com/argonautdev/public/releases/latest/download/art-linux -L -o art
- name: Configure art
run: |
chmod +x ./art
sudo mv ./art /usr/local/bin/art
art configure --key ${{ secrets.ART_KEY }} --secret ${{ secrets.ART_SECRET }}
art app deploy -f .art/argonaut-violet-ghosh.yaml --set image="${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.us-east-1.amazonaws.com/argonaut/ghosh" --set 'labels.argonaut\.dev/git-provider'='github' --set argonaut.git-provider='github' --set imageTag="${{ steps.get_sha.outputs.SHA_SHORT }}" --set appName="ghosh" --set argonaut.env="violet" --set argonaut.region="us-east-1" --set argonaut.cluster="violet" --set argonaut.serviceType="stateless" --set argonaut.imageRegistry="ecr"

This job contains the steps involved in completing deployment.

  • environment: The environment object gives information about the environment in which you are deploying your application.

The needs property has a value of build which indicates that the deploy job is dependent on the build job; therefore, the deploy job will not run if the build job isn't completed for any reason.

The first two steps of the deploy job are repeated steps from the build job. The deploy job is carried out following these steps:

  1. Fetch repo

  2. Get short SHA

  3. Download art

This action downloads the art cli on your operating system. Art is the command-line interface for Argonaut services.

  1. Configure art

A set of commands are run in sequence to configure the cli;

art configure --key ${{ secrets.ART_KEY }} --secret ${{ secrets.ART_SECRET }} configures the cli with the art key and art secret

Following the configuration, art deploys your application.