Skip to content

Release Automation #312

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
lholmquist opened this issue Aug 11, 2020 · 16 comments
Closed

Release Automation #312

lholmquist opened this issue Aug 11, 2020 · 16 comments
Labels
chore/actions Changes or additions to GitHub Workflow actions module/docs Module documentation changes module/releases Pertaining to releases of the module type/question Further information is requested

Comments

@lholmquist
Copy link
Contributor

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

@lholmquist lholmquist added chore/actions Changes or additions to GitHub Workflow actions module/docs Module documentation changes module/releases Pertaining to releases of the module type/question Further information is requested labels Aug 11, 2020
@dazuma
Copy link
Member

dazuma commented Aug 11, 2020

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
Copy link
Member

lance commented Aug 17, 2020

@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
Copy link
Contributor Author

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
Copy link
Member

lance commented Aug 25, 2020

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
Copy link
Contributor Author

lholmquist commented Aug 27, 2020

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
Copy link
Member

lance commented Aug 27, 2020

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
Copy link
Contributor Author

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
Copy link

bcoe commented Aug 27, 2020

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
Copy link
Contributor Author

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

@lholmquist
Copy link
Contributor Author

@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

@bcoe
Copy link

bcoe commented Aug 28, 2020

@lholmquist it's not today, but I'd be happy to add this functionality. If you get a moment, perhaps log a feature request? It's my goal that release-please would replace be able to replace standard-version (which I have had next to no time to work on in the past year, whereas I'm actively developing release-please).

@lholmquist
Copy link
Contributor Author

lholmquist commented Sep 2, 2020

@bcoe sorry for the reply delay, i was on PTO.

I can send a PR soon. I have something working on my fork. It looks like it needs to be updated in 2 spots. The GH action and the underlying release-please module

@bcoe
Copy link

bcoe commented Sep 2, 2020

awesome, thank you @lholmquist that will be a great feature.

@lholmquist
Copy link
Contributor Author

@bcoe not sure if you are part of the group that does the release please GH action, but i also sent a PR there to use the updated release-please functionality that i added, googleapis/release-please-action#64

@bcoe
Copy link

bcoe commented Sep 10, 2020

@lholmquist I have released release-please-action@v2.2.0, let me know if everything works for you?

@lholmquist
Copy link
Contributor Author

closing via #329 a9114b7

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
chore/actions Changes or additions to GitHub Workflow actions module/docs Module documentation changes module/releases Pertaining to releases of the module type/question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants