Skip to content

GitHub Workflows

General Remarks

The two official branches are main and production.

All workflow definition files are located in .github/workflows.
Conceptually, the workflows use the cli commands from pnpm cli located in the scripts folder. That way, you can still run all functionality locally in cases where you cannot use GitHub.

Development Flow

When a change is made to the Central CDN's source code, then these are the steps to go through:

  1. Open a development branch, taken from main.
  2. Make your changes.
  3. Create a pull request and verify that all checks succeed.
  4. this will spin up a development environment in the stage AWS account. In order to keep it (it will be destroyed by default), add the Github Label keep-deploy.
  5. Get the approval for your PR.
  6. Merge the PR back to main and verify that the CICD workflow succeeds.
  7. Your changes are now available in the stage environment.

It is a separate decision by the maintainers of the Central CDN to take the changes to prod. For that, the current state of the main branch is manually merged to the production branch. That merge triggers the CICD workflow again, this time for the account type prod. Also it will be automerged every day with all commits older than 24h.

CICD (cicd.yaml)

This is the main workflow file. It defines the deployment of stage and prod.

There are several ways how the deployment can be triggered:

  1. By a merge to main or production. This (re-)deploys the respective environment, i.e, stage or prod.
  2. By a deployment trigger. Whenever an origin param is added or changed, the deployment trigger Lambda function triggers this workflow. The payload of that trigger request contains the information whether to run the workflow for stage or prod.
  3. By a manual event. You can open the workflow page in GitHub in a browser, click the 'Run workflow' button, click the next, green 'Run workflow' button and thereby run a deployment for stage. This is not intended for prod or any dev environment.

The logic which account type (stage or prod) to use based on the incoming event and the available input data is implemented in the job set-account-type.

The cicd.yaml file also defines to run checks with every pull request on main. These checks include formatting, linting, and some tests around the deployed AWS resources.

Release

This workflow creates a new prod version.

It is manually triggered and merges the current state of the main branch to the production branch. This triggers the CICD workflow to deploy the state of the production branch to the prod environment.

Check Config (check-config.yaml)

Whenever one of the JSON files in the directory origin-config is created, updated, or deleted, this workflow is run.

It tests whether or not the content of the JSON files is valid and also checks if the given AWS account IDs make sense by temporarily deploying (and destroying) test roles.

Restore central CDN config

See Backup and Recovery for more details.

Invalidate CDN cache

A possibility to manually invalidate the CDN's cache.

Last updated: March 31, 2026 at 13:35
By: renovate-token-app[bot]