update release process documentation #7818
Conversation
ironage
added
no-changelog
no-jira-ticket
|
|
||
| 3. When ready, merge the PR. You can squash if there are only "prepare release" changes, but use a "merge-commit" strategy if there are functional changes added manually to the PR (note that if using a merge strategy, the last commit after merge will be the one tagged, so you may want to reorder the commits so that the 'prepare' commit comes last). On merge, the "make-release" action will run. This will: | ||
| 3. When ready, merge the PR. You can squash if there are only "prepare release" changes, but use a "merge-commit" strategy if there are functional changes added manually to the PR. On merge, the "make-release" action will run which triggers a Github deployment. Someone from the `@realm/realm-core-team` must approve the deployment for this step to run. Find the Github [deployment](https://github.com/realm/realm-core/actions/workflows/make-release.yml) and approve it. This will: |
There was a problem hiding this comment.
Can this be approved by the person who submitted the deployment, or does it have to be someone else?
There was a problem hiding this comment.
Yes, it can be approved by the person who initiated the deployment. The security layer is there so that only approved contributors (@realm/realm-core-team) can make a deployment and not anyone outside the organization. This is because the deployment action gets access to environment variable "secrets", which right now only consists of the URL of the slack integration that posts to our release announcement channel. I think this layer isn't strictly necessary because our branch is protected to only allow members of our org to merge pull requests, (and that is how the GHA is triggered) but it is a good security practice to put in place now, so that we can build on it as the process evolves over time.
Pull Request Test Coverage Report for Build james.stone_559Details
💛 - Coveralls |
A few updates to the docs after running through the process today.