Skip to content

Add a GitHub workflow

This section shows you how to set up a GitHub Actions workflow that builds a Docker image.

In this part of the guide you're a YAML engineer. You'll configure a GitHub Actions workflow that's used for building a container image with Docker and pushing it to Elastic Container Registry (ECR).

Want to know more?

Check out the reference material for more information about building Docker images with reusable workflows.

Before you begin

You should already have a Elastic Container Registry repository that you can push container images to.

Step 1: Add the workflow to your repository

Navigate to the root of your application repository (pirates-apps) and run:

mkdir -p .github/workflows && cd .github/workflows
ok workflows

Choose docker_build_push_and_send_dispatch_event.yml.

Rename the downloaded file to include the application environment and application name:

<app_env>-<app_name>_docker_build_push_and_send_dispatch_event.yml

For example:

pirates-dev-treasures_docker_build_push_and_send_dispatch_event.yml

Step 2: Customize the workflow variables

Open the file you just downloaded. Set these variables to match your setup:

AWS_REGION: eu-west-1
APP_NAME: treasures
RECEIVER_REPOSITORY: oslokommune/pirates-iac

Step 3: Adjust workflow triggers

See the on block in the top of the file. Adjust this to match your application setup, so that the workflow triggers when your application changes.

What can I set here?

There is not one set way of structuring the workflow. Some possibilities are:

  • On push to main
  • On tag (ideally semantic or calendar versioning)
  • On pull requests
  • On push to other branches

Step 4: Adjust the Dockerfile path

Change the build context and file path if your Dockerfile is not located in the root of your application repository:

Example for a monorepo
context: "./apps/treasures" # (1)!
file: "Dockerfile.example" # (2)!
  1. See the Docker Compose file reference for more information about the context and file options.
  2. The workflow builds the Dockerfile at ./apps/treasures/Dockerfile.example in this example. You can omit the file option if the name of your Dockerfile is Dockerfile.

Step 5: Add or remove Docker build secrets

Are you using RUN instructions in your Dockerfile that require secrets, such as when authenticating with GitHub Packages? If so, modify the DOCKER_SECRETS variable. Otherwise, you can remove the whole DOCKER_SECRETS input.

DOCKER_SECRETS: |
  GPR_USERNAME=${{ secrets.GPR_USERNAME }}
  GPR_ACCESS_TOKEN=${{ secrets.GPR_ACCESS_TOKEN }}

Using secrets in RUN instructions

Secrets in DOCKER_SECRETS are available as volumes. Use the --mount option to mount them.

Example
RUN --mount=type=secret,id=GPR_USERNAME \
    --mount=type=secret,id=GPR_ACCESS_TOKEN \
    GPR_USERNAME=$(cat /run/secrets/GPR_USERNAME) \
    GPR_ACCESS_TOKEN=$(cat /run/secrets/GPR_ACCESS_TOKEN) \
    gradle buildFatJar --no-daemon

Ask in #origo-kjøremiljø-support if you need help with this.

Step 6: Try to run the workflow

Try to run the workflow. It will fail because the workflow is not able to authenticate with AWS yet. The next section will show you how to configure this.