...
This process would separate out any release related functions from our current CI job defined in CircleCI. Since anyone can manipulate the CircleCI job on their branch, we would need to limit its capabilities, perhaps only allowing it to deploy to snapshot repositories. Then a new job could be created that handles all the release activities, and it could depend on multiple approvals or whatever mechanics we need to ensure there are no solo releases.
Pros:
- Releases are as secure as a specific job in CircleCI is.
- Developer control over day to day CI process is retained.
- CircleCI already knows how to manage secrets required for deployment.
- Mutability of the build and its metadata is under our control, and our options are anything we can script a CI agent to run.
Cons:
- Releases are as secure as a specific job in CircleCI is.
- Dual approval mechanism would have to be researched.
- Development and maintenance of the release specific job becomes a separate, non Besu-maintainer handled concern.