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 or updating a pull request.

Action: Check the pull request did not introduce unexpected label.

Recovery: Update the pull request or add a comment to trigger the action again.

Trigger: When creating or updating a pull request, or when a pull request is added to GitHub merge queue.

Actions:

• Pass the Merge queue check status check on pull requests so they remain in a mergeable state,
• When a pull request is enqueued in GitHub merge queue, post a /merge comment to trigger the Datadog merge queue,
• Fail the Merge queue check status check on merge groups to prevent GitHub from merging directly.

Recovery: The workflow is expected to fail to block GitHub merge queue. This redirects GitHub's "Merge when ready" button to the Datadog merge queue system.

Trigger: When a git tag matching the pattern "vM.N.0" is pushed (e.g. for a minor release).

Action: Create a release branch that corresponds to the pushed tag (e.g. "release/vM.N.x"). Then open a PR against the release branch that pins system tests.

Recovery: Manually create the release branch from the "vM.N.0" git tag, and pin system tests to this branch by running the ./tooling/update_system_test_reference.sh script.

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: 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: Quarterly released, loosely a day after the new image tag is created.

Action: Update the Docker build image used in 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: When creating or updating a pull request targeting master, or when labels are updated.

Actions:

• Fail the PR if a new Groovy test file is added to a module listed in .github/g2j-migrated-modules.txt (hard enforcement),
• Post a warning comment on the PR if a new Groovy test file is added to any other non-exempt module (soft warning). Instrumentation (dd-java-agent/instrumentation/) and smoke-test (dd-smoke-tests/) modules are exempt from this warning.

Recovery: Re-write the Groovy test files in Java / JUnit 5. To override this check entirely, add the tag: override-groovy-enforcement label to the PR. Remove the label to re-enable enforcement.

Notes: The migrated modules list is always read from master. Add a new entry to .github/g2j-migrated-modules.txt each time a module is migrated to Java / JUnit 5.

Trigger: Every day or manually.

Action:

• Run GitHub CodeQL action, upload result to GitHub security tab -- do not apply to pull request, only 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: When pushing commits to master or manually.

Action: Build the Java Client Library and runs the system tests against.

Recovery: Manually trigger the action on the desired branch.

Trigger: Every week or manually.

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

Recovery: Manually trigger the action again.

Trigger: Monthly or manually

Action: Creates a PR updating the git submodule at dd-java-agent/agent-jmxfetch/integrations-core

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. Docker and GiHub CLI need also to be installed. The .github/workflows/tests/ folder contains test scripts and event payloads to locally trigger workflows.