Add GitHub Action to trigger vTDS test deployment

[davidfluck-hpe]

Pull Request Template

Description

This changeset adds a GitHub Action that will trigger vTDS deployments from pull request branches when an approved user (i.e. one with writer, maintianer, or admin permissions) comments /deploy on a pull request. The action will then deploy the HEAD of the PR branch.

It does this primarily with github-script@v9, which is a GitHub-provided utility action for interacting with the GitHub API in a more friendly manner via JavaScript. That code looks for the /deploy comment, checks it against the commenter's repository access, and then triggers a deployment if the user has the correct acess.

This functionality sidesteps several GitHub Actions-related security risks, especially if pull requests are made from forks.

Additional work

This requires some out-of-band work that only a select few admins/org owners can provide, namely:

1. A GitHub app in the OpenCHAMI GitHub org with the following permissions:
   • Read and write Repository Contents.
   • Read and write Issues.
   • Read and write Pull Requests.
   • Read-only Metadata (mandatory).
2. A GitHub app in the HPE GitHub org with the following permissions:
   • Read and write GitHub Actions.
   • Read-only Metadata (mandatory).

The OpenCHAMI GitHub App is necessary for the action to do things like read PR comments, while the Cray-HPE GitHub App is necessary to trigger the workflow_dispatch endpoint to kick off the vTDS deployment action.

Then, the following secrets need to be created within the OpenCHAMI/release repository:

• OCHAMI_APP_CLIENT_ID: the installed OpenCHAMI GitHub App client ID
• OCHAMI_APP_PRIVATE_KEY: the installed OpenCHAMI GitHub App private key

Additionally, the following secrets need to be created within the Cray-HPE/openchami-vtds repository:

• HPE_APP_CLIENT_ID: the installed HPE GitHub App client ID
• HPE_APP_PRIVATE_KEY: the installed HPE GitHub App private key

Caveats

Testing this involved working from private repositories under the same GitHub user, which changes the permissions structure a bit. I believe the github-script code should work as written, but there's a small chance there's a syntax error or something; it's just difficult to test cross-org permissions stuff like this. I'm happy to fix anything that breaks, just let me know.

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

---

For more info, see Contributing Guidelines.