Skip to content

Latest commit

 

History

History
152 lines (92 loc) · 5.09 KB

CI.md

File metadata and controls

152 lines (92 loc) · 5.09 KB
Raw

Project CI Infrastructure

We use GitHub Actions to help automate testing and deployment.

Note

Since this document is manually updated, parts of it may be out of date. If you notice anything in this document does not match the CI, please contact a member of the team who is familiar with the workflows to update this.

Workflows

test

Runs all automated tests when there is a PR against master.

deploy

This job is triggered after a push to master. It does two things:

  • Runs all automated tests.
  • If the tests pass, it checks if there is a tag associated with the current build number.
  • If there’s no tag for the associated build, it attempts to upload a new build to App Store Connect.
  • If the build is successful, it adds the relevant tag to the repo.

The build tags are in the form $variant-v$version-$build. For example:

  • scenarios-v1.0-4
  • production-v1.0.3-178

monitor-version

This jobs runs periodically. It checks the build number on master. If there’s a tag for the build number, but there has been new commits since then, it will increment the build number and commits to master.

The script looks for tags of the currect shape, with correct variant set to scenarios and build set to the current build number, but ignores the version. For example, these would both match as a tag for build 5:

  • scenarios-v1.0-5
  • scenarios-somethingelse-5

These would not match:

  • scenarios-v1.0-4
  • production-v1.0-5
  • scenarios-multiple-parts-5

report

This jobs runs periodically. It

  • runs UI tests in “report” mode. This will generate screenshots and content that is used for documentation.
  • creates an archive of the app and uses it to generate artefact reports.
  • generates static web content from these reports and uploads them as artefacts.

Secrets

Access to other repos

GitHub provides builtin API tokens as part of the workflow to access the current repo. Access to other repositories is managed separately.

REPOS_ACCESS_ACTOR

Username of an account in the Service Accounts GitHub team.

Accounts in this normally only have read access to other repos.

REPOS_ACCESS_TOKEN

Personal access token for REPOS_ACCESS_ACTOR with repo permissions.

Access to AWS

Test and App reports get uploaded to an S3 bucket for further visualization and documentation tools to consume. To perform this, a technical user account is used. The build environment authenticates as that user programmatically via access key ID and secret access key. The user's access is limited to the dev-mobile-build-reports, where they are permitted to s3:PutObject, s3:GetObject, s3:ListBucket and s3:DeleteObject.

AWS_ACCESS_KEY_ID

Access key ID for the technical user.

AWS_SECRET_ACCESS_KEY

Secret access key for the technical user.

Apple Development

BASE64_ENCODED_IDENTITY

This is a base64 encoded p12 file, containing an Apple Distribution identity (private key and certificate).

IDENTITY_PASSWORD

Password of the BASE64_ENCODED_IDENTITY p12 file.

BASE64_ENCODED_PROFILE

A distribution provisioning profile with necessary entitlements for App Store builds.

This profile should have correct entitlements for the app. The profile should use a wildcard app ID as it will be used for both Production and Scenarios apps.

App Store Connect

ASC_API_KEY

An App Store Connect API Key. This key must have developer role access to the app on App Store Connect.

This key is the content of the p8 generated by App Store Connect without any modifications.

ASC_API_KEY_ID

The ID of the key.

ASC_API_KEY_ISSUER_ID

The issuer ID for the key.

Access to Lokalise

Copy for the app is managed in Lokalise. We use a script to download the latest copy and import it to the app.

LOKALISE_PROJECT_ID

The project id for this project on Lokalise.

LOKALISE_API_TOKEN

The API token from Lokalise to get access to the copy for this project