Release Automation

[lholmquist]

Currently, as outlined in the Release guidelines docs, it is a manual process.

This issue is to be used to start to brainstorm ideas on how to make our release process more automated and less manual.

Some steps that need to be included:

• Run the release scripts with GH actions
• Create a new Release on Github
• Publish to npm

I'm sure there are more, but that is what the issue is about, coming up with a procedure as a community

[dazuma]

We could consider a process like https://github.com/googleapis/release-please which was developed by the people behind conventional commits and is currently being used at Google to automate releases for hundreds of API client libraries across many languages. (Full disclosure: my day job is on that team.)

The basic idea is to

• trigger (e.g. a GH action) on new commits
• interpret conventional commit messages to determine the correct semantic version bump (patch/minor/major)
• generate changelogs automatically based on the same conventional commit messages
• automatically open a PR with the version bump and changelog (and automatically update it as more commits are added)
• then, once a human decides to do a release, they merge the PR (and of course they have the option to edit the version/changelog manually if desired)
• a separate process can then trigger on that PR merge, and perform the release, i.e. creating a GH release, building a package, and publishing to npm

[lance]

@dazuma this is pretty interesting. We already have steps 1-3 in place. Steps 4-6 are essentially what @grant suggested here and what prompted the creation of this issue. I wasn't aware of release-please, however. Thanks for the pointer.

[lholmquist]

this workflow looks really nice. the only problem I can see is the 2FA for npm. in the release-please docs, https://github.com/googleapis/release-please#automating-publication-to-npm , it says to "keep 2FA enable, point the the registry url to your own wombat dressing room". So in order to use that, we would need to have that running and hosted somewhere.

[lance]

As discussed on Slack, let's go ahead and try to get release-please in place without automated publishing to npm for the next release (3.2.0).

[lholmquist]

I started to play around with adding release-please to my fork. For the most part, I like what it is doing, and it does all the things we are looking to automate, but there are a couple things that I think we need to fix before we can add it .

This first is that it is not taking into account that my default branch is main instead of master. so all PR's have been going to master. I did add in the action before i switched my default branch, so maybe that is an issue, but i will test it again

edit: I was using a old version and the latest version of the action works fine with main

The second is that in our package.json, we have rules setup for standard-release that unhide certain commit message types, so they show in the changelog. It doesn't look like at the moment this can be done with release-please.

We also need to make sure we are signing the release PR, which we could do manually once it is approved, but that would defeat the purpose of using automation.

I'll see if I can add these things in and either send a PR, or create our own fork of it.

[lance]

I started to play around with adding release-please to my fork. For the most part, I like what it is doing, and it does all the things we are looking to automate, but there are a couple things that I think we need to fix before we can add it .

Thanks for looking into this @lholmquist. I poked around the source for the project and found some things that might help.

edit: if i have no master branch, the action fails, so it must be looking for master

It looks like you can add a default-branch parameter to set the branch to main.

The second is that in our package.json, we have rules setup for standard-release that unhide certain commit message types, so they show in the changelog. It doesn't look like at the moment this can be done with release-please.

You might try extracting the standard-version stanza from package.json and put it into a conventional changelog config file.

[lholmquist]

It looks like you can add a default-branch parameter to set the branch to main.

I was using an old version, since i copy/pasted, latest version is fine now

[bcoe]

Just catching up on this thread, I wanted to share this with you:

https://github.com/GoogleCloudPlatform/release-please-action

It's a GitHub action that runs release-please, here it is in action. The main reason I opt for the GitHub app, rather than the action, for Google projects is related to CLA.

[lholmquist]

@bcoe thanks, that's actually the action text that i ended up copying and running into the master/main issue

[lholmquist]

@bcoe something I wanted to ask. Is it possible to have the release-please action use a standard-release config to show more types in the changelog? I've tried to add a .versionrc.json with something like this:

{
  types: [
    type: ....
  ]
}

but i don't think it is recognizing it. It is also completely possible, I've written the config file incorrectly