chore: bootstrap release-release for automatic changelog & version changes

[JimmyLv]

Configuring release-please for multiple node packges by using manifest-releaser, https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md

• added google-github-actions/release-please-action@v3
• using node-workspace plugin, to update all packages' version with dependency
• updated the "group-pull-request-title-pattern" to "chore: release v${version}"

Demo

Please see chore: release v6.74.1 by github-actions[bot] · Pull Request #7212 · ParabolInc/parabol

Temporarily configuring the default-branch(37b16a1) to release-please/bootstrap/default, creating the expected effect of draft PR at #7212 as a demonstration.
After this PR merge, a new release-please PR will be created based on the latest changes to master.

One detail to note: in addition to CHNAGELOG in the root directory, a CHNAGELOG.md file is also generated in each packages/* directory, but the update log only contains the contents of the submodule. From my research, there is no release-please configuration found to remove at the moment.

ACs

• changelog entries do not have fix, chore prefix etc.
• category/component of prefix is added in bold, i.e. chore(DX): add release draft notes is converted to **DX**: add release draft notes
• will update the Release Playbook after this PR merged to master

[JimmyLv]

Hey @Dschoordsch @rafaelromcar-parabol , I updated the Release Please workflow, but still need to discuss with you about the overall release process, for now (you can see the demo above):

1. If the bot help to create a release PR with base branch being master, that means we don't need to do some manual version updates in Release Playbook
2. but for the staging branch to release, is it after the PR is merged, or should happend before? Or should we merge the PR to staging and then merge it back to master after we release the production branch?
3. this workflow doesn't support -rc1 pre-release yet, but I think if full automation is needed here should require a little tweaking

[Dschoordsch]

2. but for the staging branch to release, is it after the PR is merged, or should happend before? Or should we merge the PR to staging and then merge it back to master after we release the production branch?

The bot should create a PR that targets staging with the release version and changelog entries prepared. Release owner reviews it, merges it and then staging is tested.
Once staging is tested, I suppose we would merge it to production and then production to master.

I wonder how the bot would do the tags in this case? This would only work for fast-forward merge, wouldn't it?

[rafaelromcar-parabol]

If it targets Staging, it would only create the PR and add the content once we have merged master into staging, isn't it? We will then not see the changes that are merged into master and waiting to be released.

I would say we could change our current release process to something like:

• Merge production into master
• Release Please adds whatever was missing and we merge the PR if we are ok.
• Merge master into staging (that deploys to staging) using git checkout staging && git merge vA.B.C
  • If something goes wrong, we make changes in staging until it works as fix(component) and we merge staging into master. That creates a new Release Please PR that generates a new version of the app (new patch in that case). We merge the PR and release the new version in master. We then merge master back to staging again, to release it again.
• Merge into production using git checkout production && git merge vA.B.C and that deploys to production.
  • If something goes wrong, hot-fixes in production that are sent back to master and a new version generated and we do the above process again, merging that new tag into production to release it.

I see a problem: we should not merge anything into master while the release is ongoing. But well, I think it's not a big deal to do that at the end. It does not stop developers from working, it just stops integrating their work into master for a while.

Just remember that once we would be into the Kubernetes logic, we will only have master and dev-branches. No prod and no staging. Master will be used to test things and build the docker image everything we merge the PR from Release Please (actually, every time there is a tag). Then, deployment will be done in a different place using a similar logic to the one I just described.

[rafaelromcar-parabol]

I was playing with release-please in the terraform module I'm building for the future GCP deployments and I found out it doesn't add to the Changelog commits starting with chore or anything else than fix and feat I think.

Also, I think that, if using release-please, we really should start using the scope in all our commits to master. It makes the changelog much easy to read that way. Here is my current PR by Release Please

[JimmyLv]

I wonder how the bot would do the tags in this case? This would only work for fast-forward merge, wouldn't it?

@Dschoordsch When the Release PR is merged, release-please should automatically add the corresponding git tag. As the document said:

1. Updates your changelog file (for example _CHANGELOG.md_), along with other language-specific files (for example _package.json_).
2. Tags the commit with the version number
3. Creates a GitHub Release based on the tag

And that PR will go through these lifecycles in the process: autorelease: pending -> autorelease: tagged -> autorelease: snapshot -> autorelease: published (for this final step, release-please does not automatically add this tag, but we recommend it as a convention for publication tooling) ¹

Footnotes

1. https://github.com/googleapis/release-please#whats-a-release-pr ↩

[JimmyLv]

If it targets Staging, it would only create the PR and add the content once we have merged master into staging, isn't it?

@rafaelromcar-parabol yes, this could be interesting. I just got another very simple solution:

• Just change the Pull Request's base branch from master to staging and do the merge when releasing.

I see a problem: we should not merge anything into master while the release is ongoing. But well, I think it's not a big deal to do that at the end. It does not stop developers from working, it just stops integrating their work into master for a while.

If staging is seen as a temporary release branch, as an intermediary, then PR changes will be merged back through release pr branch -> staging -> production -> master. In fact, it's the same way that the master branch is used as the base branch.

• of course, If there is a bug in the staging environment, the fix is based on the staging environment, as an intermediate temporary state (rc-1, rc-2... ), which has no effect on the final production version number.

---

🤔 What if the branch created by the release PR is deployed directly to the staging environment each time? (i.e. as a notional staging branch):

• Still use master as the base branch
• The branch of the PR created by the release-please is named release-please-branches--master, here's a real-world example: chore(master): release 9.5.0 conventional-changelog/standard-version#867
• Merging to staging
  • option 1: change the Pull Request's base branch from master to staging, then merge to stating which trigger the deployment on CI
  • option 2: 🤔 Currently staging branch is not normally used, if we allow deployments every time when a new update is pushed to the PR, we can also find any deployment issues in advance (e.g. the Nx issue in this v6.75.0 deployment, Slack)
• Each time we get to release day, Release Owner just needs to verify that the staging env meets the test requirements
• If everything is OK, Release Owner can actually merge from the staging (release-please-branches--master) branch directly into the production branch
• Then finally merge the production branch back to master, and the changelog, version number and Git Tag are all merged to the master.

Is it theoretically possible? I think I'll add a diagram of the branches later to make the flow clearer. 😁

[JimmyLv]

I've added the Git branching diagrams, hopefully it will help:

1. Before: Manually update CHANGELOG.md & versions
   

2. After: Automatically create the release PR to update CHANGELOG.md & versions
   

3. Final: Deploy PR branch before merge based on K8s, only have master and dev-branches (the release pr will also be deployed)
   

view on diagrams.net (previously draw.io)

[Dschoordsch]

@JimmyLv I'm not sure I get the full picture. How is this whole process triggered?
The flow of a bot branching master with changelog and version changes seems sensible.
To my understanding the flow is

1. somehow the bot is triggered, it creates a PR with CHANGELOG.md and version changes targeting staging
2. release owner checks and merges the PR
3. after the PR was merged, the bot needs to come in and tag the commit
4. tests are done on staging
5. staging is merged to production ff-only
6. production is merged to master

Would this bot do 1) and 3)?

@rafaelromcar-parabol I'm strongly opposed to having a merge freeze to master, that wouldn't be a step forward.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[JimmyLv]

Would this bot do 1) and 3)?

@Dschoordsch yeah, your understanding is exactly correct! the bot will tags the commit with the version number.

1. somehow the bot is triggered, it creates a PR with CHANGELOG.md and version changes targeting staging
2. release owner checks and merges the PR

For 1) and 2), I would like to add: currently, the Bot only can monitor one branch and create a PR for the corresponding branch, so the Release Owner needs to manually change the PR base from master to staging and then merge it, thus this PR actually includes these 2 steps (previous manual):

1. merge the master Git changes to the staging branch
2. change the package version number on the staging branch

How does that sound?

[mattkrick]

Just a question about hotfixes-- today we branch off of production & merge the hotfix back to production. This is because master (and staging, technically) could have additional PRs that we don't want to introduce at the same time as the hotfix. Would this be the same going forward?

[Dschoordsch]

Would this bot do 1) and 3)?

@Dschoordsch yeah, your understanding is exactly correct! the bot will tags the commit with the version number.

You linked the documentation before, but it lists the steps in the wrong order, that's why I was asking. When we merge the PR, we will do a squash+rebase, i.e. the hash changes and the tag is no longer valid. Does it update the tag after the PR was merged?

1. somehow the bot is triggered, it creates a PR with CHANGELOG.md and version changes targeting staging
   release owner checks and merges the PR
2. release owner checks and merges the PR

For 1) and 2), I would like to add: currently, the Bot only can monitor one branch and create a PR for the corresponding branch, so the Release Owner needs to manually change the PR base from master to staging and then merge it, thus this PR actually includes these 2 steps (previous manual):

1. merge the master Git changes to the staging branch
2. change the package version number on the staging branch

How does that sound?

Sounds ok from a workflow perspective.

[JimmyLv]

@mattkrick yeah, hotfix is the case. I found release please support multiple release branches, so it can monitor master and production branches by configuring multiple workflows that specify a different default-branch:

Configuration for production branch (.github/workflows/release-production.yaml):

on:
  push:
    branches:
      - production
name: release-please
jobs:
  release-please:
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          default-branch: production

So when branching off of production & merge the hotfix back to production, the release-please bot will automatically create the release PR to automatically modify the versions and CHANGELOG, and of course eventually the production branch will merge to master.

[JimmyLv]

Hey @Dschoordsch , you're correct 😁 it lists the steps in the wrong order.

So I tried it out myself to verify, and after this Release PR #7229 (using the staging_2_test_and_will_delete branch) merged, the corresponding Git Tags were created successfully. (will delete them later)

By the way, I found that the git tags contained package component names, so I changed the include-component-in-tag configuration ¹.

Could you please revisit the workflows config file for this PR?

Footnotes

1. https://github.com/googleapis/release-please/blob/main/schemas/config.json#L77 ↩

[Dschoordsch]

Let's try this. I propose when we merge this now, you should do the next release and update the Release Playbook to the new workflow.

[Dschoordsch]

+1 I just did the release and this should now be 6.76.0

[JimmyLv]

As this week's Release Owner, I will first merge this PR, to see if it works properly to create the Release PR, after which I will update the Release Playbook to the new workflow.