Skip to content

GitHub Actions

GitHub Actions are specified as individual 'workflows' through the use of yaml files.

For example, our main production deployment workflow is specified in: 

.github/workflows/deploy-prod.yml

It's sometimes useful to merge code without triggering a configured workflow. To do this, disable it by selecting the workflow, then clicking on three-dot menu next to 'Filter workflow runs', then clicking 'Disable workflow'.

Workflows that involve deploying code to Azure need to use the approprate Azure credentials. GitHub provides a native means of storing any credentials securely as a 'secret'. A GitHub 'secret' is just a textfield with a label, but importantly, workflow yaml files can access secrets.

For example, among others, the main production deployment workflow file mentioned above (deploy-prod.yml) makes reference to:

secrets.AZURE_CREDENTIALS_PRODUCTION

This secret holds the Azure client secret that facilitates deployment. It has an expiry date so will need always require updating at some point. It's usually clear when the Azure client sceret has expired as the deployment fails when trying to login to Azure.

Updating the Azure client secret (on the Azure side)

Unless you have required permisions this will likely require assistance from Technology.

  • The Azure client secret for preprod needs to be set under 'Certificates & scerets' in the application 'wagtail-wrkflw-spn'
  • The Azure client secret for production needs to be set under 'Certificates & scerets' in the application 'wagtail-tate-production'

Updating the Azure client secret (on the GitHub side)

The above step should provide value for each secret. This value, alongside a few other details is then included in the 'secret' set in GitHub.

To ensure a successful connection to Azure, the secret in GitHub has to use the below json format.

{
  "clientId": "[ 'Application (client) ID' of the application (under 'Overview') ]",
  "clientSecret": "[ 'Value' of a valid secret in the application (under 'Certificates & secrets') ]",
  "subscriptionId": "aeaa672e-6198-4131-9692-4136ae13bee1",
  "tenantId": "[ 'Directory (tenant) ID' of the application (under 'Overview') ]",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Note, use the same 'subscriptionId' value (as stated above) for the json block for both AZURE_CREDENTIALS_PREPROD and AZURE_CREDENTIALS_PRODUCTION.

Expiries

The client secret in wagtail-wrkflw-spn expires on:

09/08/2023 (8th Aug)

The client sceret in wagtail-tate-production expires on:

10/21/2024 (21st Oct)

Workflow dependency caching

We use the npm and poetry package managers to handle dependencies during deployment. The respective 'actions' for these package managers used in the workflow yaml files, setup-node and setup-python, automatically create caches where necessary to speed up deployments.

If during the actions run an issue occurs that appears to be cache-related, deleting the asccociated cache may be useful.

To do so, go to the 'Actions' tab in the GitHub repo UI, select 'Caches' (under 'Management'), then use the 'delete' (trash) button against the cache to be deleted (a prompt to confirm the deletion will appear).

Note - The relevant cache is likely to be based on main as preprod uses the main branch directly and a production branch will always be based on the main branch (and therefore also use any main branch depedency caching).