search

bitcrowd / tickety-tick

A browser extension that helps you name branches and write better commit messages
MIT License
57 stars 10 forks source link

Automate releases #296

Closed pmeinhardt closed 1 year ago

pmeinhardt commented 3 years ago

Attempt number 4. 😅

UPDATE

We can now automatically upload to Chrome Web Store and Mozilla Add-Ons. Plus: we also create a GitHub release with automated notes.

TODO

The branch protection on the main branch may still be an issue for the automation...

pmeinhardt commented 3 years ago

Next time we release, let's take this for another test ride and merge if its okay. We probably should update the README before merging.

pmeinhardt commented 2 years ago

Looks like signing with web-ext now works – cf. https://github.com/bitcrowd/tickety-tick/pull/249#issuecomment-652050512. Note: I only tried for unlisted versions so far.

yarn build:firefox && WEB_EXT_API_KEY=xxx WEB_EXT_API_SECRET=xxx yarn sign
yarn run v1.22.17
$ web-ext sign --source-dir ./dist/firefox --artifacts-dir ./dist --channel=unlisted
Applying config file: ./package.json
Building web extension from /Users/pmeinhardt/Code/bitcrowd/tickety-tick/dist/firefox
Validating add-on [...................................................................................]
Validation results: https://addons.mozilla.org/en-US/developers/upload/xxx
Signing add-on [......................................................................................]
Downloading signed files: 100%
Downloaded:
    dist/tickety_tick-5.0.0unlisted-an+fx.xpi
Extension ID: jid1-ynkvezs8Qn2TJA@jetpack
SUCCESS
✨  Done in 273.78s.
klappradla commented 2 years ago

Looks like signing with web-ext now works – cf. #249 (comment). Note: I only tried for unlisted versions so far.

Wow 🤯

klappradla commented 1 year ago

Small update: web-ext-sign has a flag to use the new submission API now.

klappradla commented 1 year ago

Quick braindump from other bitcrowdies and how things are handled on Elixir open source projects: have a two step process for the release:

  1. Manual PR for version change
  2. Tag and release

Idea: script/release could be limited to do only these steps:

  1. Tag current commit and push the tag
  2. Create GH release
  3. Release to stores

Doing so, we'd run yarn version to bump the version (and remove the generated tag directly), manually submit and merge this as a PR and then run script/release separately.

This yields the potential problem of releasing "the wrong commit", but maybe that risk is tolerable 🤷

klappradla commented 1 year ago

Went for a two step process now @pmeinhardt, in order to align with other bitcrowd open source projects and to not limit releasing to admins only:

  1. PR with version bump (yarn prepare-release)
  2. Actual release pipeline (yarn release)

This still yields the change of tagging the "wrong" commit with the version. But in practice, we can assume that steps 1 and 2 are pretty much directly after each other and there won't be much happening aside that.

What do you think?

pmeinhardt commented 1 year ago

Went for a two step process now @pmeinhardt, in order to align with other bitcrowd open source projects and to not limit releasing to admins only […]

What do you think?

Sure thing. You are the ones cutting the releases, so the process has to work for you. ✌️

I haven't had a closer look, but from the short description it sounds like the time between steps 1 and 2 doesn't matter. What matters is that 2 happens after the PR from 1 is merged. Is that right? If so it might be worth adding to the release guide (or adding a check at the start of the yarn release script if you haven't done so).