Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Cutting a release #1353

Closed
JustinBeckwith opened this issue Feb 1, 2020 · 7 comments
Closed

Cutting a release #1353

JustinBeckwith opened this issue Feb 1, 2020 · 7 comments

Comments

@JustinBeckwith
Copy link
Contributor

Greetings folks! I'd like to be able to cut a release if possible. After we have a new release or two out, and stabilized, I'd also like to start automating releases so we're not dependent on any individual to keep things going, rather group owned credentials.

  • Is the process for cutting a release documented today? I see npm run release, which appears to create a tag and compiled assets. It's unclear how this dovetails with running npm publish.

  • Would it be possible to add google-wombot as an admin on the protobufjs package on npm? Alternatively, could we add justinbeckwith, fenster, or bcoe so we have someone with admin?

  • Would it be possible to expand the list of users with admin on the repo, to include JustinBeckwith, alexander-fenster, and bcoe, so we can set up a little more automation?

@dcodeIO - I realize this is askin a lot, but we really do want to make sure things can keep rolling here, especially dependency updates :)

@alexander-fenster @bcoe as FYI

@bcoe
Copy link
Contributor

bcoe commented Feb 1, 2020

would love to pitch in as best I can, I've been using the automation machinery our team has been building on projects I manage, such as yargs.

@dcodeIO
Copy link
Member

dcodeIO commented Feb 3, 2020

There isn't really a release process in place as of today. Mostly a bunch of scripts to do it manually, with npm run release being a shorthand to run all the relevant tasks before issuing a publish.

I'm open to your suggestions and google-wombot seems like a great tool. An alternative might be to do something like we do over at AssemblyScript, which is solely based on GitHub Actions, not much more than a few lines of GH actions code. Publishes nightlies once a day if there have been changes, respectively creates releases if the version in package.json changes.

@JustinBeckwith
Copy link
Contributor Author

Both approaches sound awesome to me - the biggest thing I'd like to see is automation so we don't have to bug you :)

I take the semantic-release release approach in my projects, which cuts a new release every time a relevant PR is landed. You cna see an example of combining that with GitHub Actions here.

That could be heavy handed for some, which is why I like the release-please approach that queues up PRs with the changelog, and lets a maintainer merge them for the machinery to kick in. The nightly approach also sounds great. Anything that gets us automation basically lol.

@dcodeIO
Copy link
Member

dcodeIO commented Feb 3, 2020

While looking into this, I started wondering what to do with the support packages in lib/. These are currently independently versioned and would need some special logic. The easy route would be to make these use the exact version of the main package and publish these even if there haven't been any changes, but that'd create a lot of unnecessary publishes since these rarely change. How would you tackle this?

Other than that, I set up the integration so far that there's an NPM_TOKEN (of the protobufjs acount on npm with access to all the packages) in GH actions that can be used for publishing now and once everything is sorted out should be as easy as removing Travis-CI and putting the workflows into place.

@bcoe
Copy link
Contributor

bcoe commented Feb 3, 2020

@dcodeIO if you want to bring it to email bencoe @ google.com, I think I could help you plug in some of the automation we've been working on for the community. The only caveat is a slight change in how commit messages are written (moving to conventional commits). I'd be happy to help with the infrastructure so that:

  1. it's still published under whatever account you'd like to use, but.
  2. has an automated draft PR for releases using release-please.
  3. has 2FA enabled.

@dcodeIO
Copy link
Member

dcodeIO commented Feb 3, 2020

Heh, that PR alone was enough to trigger some bitter sweet nostalgia, ultimately leading to a journey through the code I once cared for so much, at a time when I was overly optimistic that stuff will pay off one way or another some day. Still wish I had a month or two to sink into the repo to modernize it, but well. I guess my adventures so far have made me more of an expert in making software that isn't sustainable and will ultimately rot than I've become the expert I once went to become. And yeah, right now this makes me question a lot more than it should, ignore me :)

That being said, I've added google-wombot to all the relevant packages on npm, made JustinBeckwith and alexander-fenster owners of the protobufjs org, and invited bcoe.

@alexander-fenster
Copy link
Contributor

This is working great now, with auto-releases and all such things. Closing :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants