This lists and describes the repository GitHub actions, how to maintain and test them.

Trigger: When a PR targeting master or a patch release (release/vM.N.x) branch is closed.

Action: Attach the corresponding milestone to the closed pull request (if not set).

Recovery: Attach the milestone by hand to the PR.

Trigger: When a release is published.

Action: Append the new release to the Cloud Foundry repository.

Recovery: Manually edit and push the index.yml file from the cloudfoundry branch.

Trigger: When creating or updating a pull request.

Action: Check the pull request complies with the contribution guidelines.

Recovery: Manually verify the guideline compliance.

Trigger: When creating a tag, or manually (providing a tag)

Actions:

• Fetch merged pull requests from the related tag milestone,
• Generate changelog draft,
• Create a new draft release for given tag with the generated changelog.

Recovery: Manually trigger the action again on the relevant tag.

Trigger: When creating a minor or major version tag.

Actions:

• Close the milestone related to the tag,
• Create a new milestone by incrementing minor version.

Recovery: Manually close the related milestone and create a new one.

Notes: This action will not apply to release candidate versions using -RC tags.

Trigger: Quarterly released, loosely a day after the new image tag is created.

Action: Update the Docker build image used in CircleCI and GitLab CI with the latest tag.

Recovery: Download artifacts and upload them manually to the related download release.

Notes: Manually trigger the action again given the desired image tag as input.

Trigger: When a release is published.

Action: Update the download releases with the latest release artifact.

Recovery: Download artifacts and upload them manually to the related download release.

Notes: Download releases are special GitHub releases with fixed URL and tags, but rolling artifacts to provided stable download links (ex latest and latest-v1).

Trigger: When a release is published. Releases of type prereleased should skip this.

Action:

• Find all issues related to the release by checking the related milestone,
• Add a comment to let know the issue was addressed by the newly published release,
• Close all those issues.

Recovery: Check at the milestone for the related issues and update them manually.

Trigger: Every day or manually.

Action: Clean up old lib-injection OCI images from GitHub Container Registry.

Recovery: Manually trigger the action again.

Trigger: Every month or manually.

Action: Mark as stale and comment on pull requests with no update during the last quarter. Close them if no following update within a week.

Recovery: Manually trigger the action again.

Trigger: When pushing commits to master or any pull request targeting master.

Action:

• Run GitHub CodeQL action, upload result to GitHub security tab -- do not apply to pull request, only when pushing to master,
• Run Trivy security scanner on built artifacts and upload result to GitHub security tab and Datadog Code Analysis.

Notes: Results are sent on both production and staging environments.

Trigger: When creating a PR commits to master or a release/* branch with a Git Submodule update.

Action: Notify the PR author through comments that about the Git Submodule update.

Trigger: Every week or manually.

Action: Create a PR updating the Grade dependencies and their locking files.

Recovery: Manually trigger the action again.

GitHub actions should be part of the repository allowed actions to run. While GitHub owned actions are allowed by default, the other ones must be declared.

Run the following script to get the list of actions to declare according the state of your working copy:

find .github/workflows -name "*.yaml" -exec  awk '/uses:/{print $2 ","}' {} \; | grep -vE '^(actions|github)/' | sed 's/@.*/@*/' | sort | uniq

Workflows can be locally tested using the act CLI. The .github/workflows/tests/ folder contains test scripts and event payloads to locally trigger workflows.