The development workflow will run the workflow on every push to a branch that is not the main branch. It will create a new release that is promoted to a channel with the same name as the branch. The next job will setup a compatibility matrix of clusters, deploy the app and execute some tests. Once everything is successful the created clusters and customers will be removed again. Based on your preference you can either use the simplified prepare-cluster version, or the highly customizable version.
See the example workflow for more details and also the prepare-cluster directory for the actual action.
See the example workflow for more details.
See the example workflow for more details.
The releasing workflow will run the workflow each time a tag is being placed on the repository. It will create a new release that is promoted to a channel with the same name as the tag. The next job will setup a compatibility matrix of clusters, deploy the app and execute some tests. Once everything is successful the release will be promoted to the stable channel. And the created clusters and customers for the compatibility matrix will be removed again.
See the example workflow for more details.
Because these actions require use of the Replicated API token--commonly provided in a repository secret--it is important to understand some of the intrinsic details of how GitHub Actions treats secrets in certain scenarios.
A common use case for integrating GitHub Actions with Replicated may be during the pull request (PR) process. For example, you may choose to build a GitHub Action which creates a cluster and runs any number of tests in a Replicated environment when a PR is sent to your repository. By default, GitHub does not allow access to repository secrets when an Action is triggered from a remote fork because the fork is considered untrustworthy. See the note in the GitHub documentation here. In the case of Replicated's GitHub actions, since the API token is a required input, if the secret cannot be loaded the workflow step which invokes the Replicated API will fail.
In order to provide a secure experience, we recommend the following process.
- Use workflow approvals to prevent Actions from firing by default unless approved by a repository user with write access. See the GitHub documentation here for more information.
- Carefully inspect the PR prior to approving workflows to run.
- Use the
pull_request_targettrigger in the Action which calls the Replicated service along with the status which should trigger the workflow. An example snippet is shown below. Note that this is only required if an Action which uses a Replicated step must fire on a PR from a fork as described previously.
For further reading on security in GitHub Actions, see this three-part blog series which goes into further depth.
In this below snippet, the pull_request_target trigger is used in one of four possible states which serves to invoke an Action which uses a Replicated step. Use of the more common pull_request trigger is preferred if such an Action does not need to be invoked upon PRs from forks.
name: Replicated demo
on:
pull_request_target:
types: [opened, synchronize, reopened, ready_for_review]