Release Automation - Githubissues

decanTyme commented 1 year ago

As explained here, I'm looking to re-release as 0.x and therefore looking at some alternatives to semantic-release. Will update this as more testing is done.

release-please - An alternative by Google that seems to support the preferred 0.y.z handling, though it seems tied to GH Actions and I still don't know if its "automation" workflow makes sense for this (I want to able to just push, merge changes and have it uploaded directly to npm without worrying about anything else). This is by far the best bet on this list.
release-it - I read that it also has the preferrable 0.y.z handling but upon testing it out, it doesn't seem to be that way (i.e. it bumps to 1.0.0 when breaking changes are found; using the @release-it/conventional-changelog plugin and conventionalcommits preset). Seems nice though for manual version releases, as it prompts on what version should be released (non-CI). Can be configured for CI with shareable plugins.
standard-version - Should've been next in line for its preferred implementation of 0.y.z handling but is now deprecated, so it's not high on the list anymore. There is a promising fork though.

To be honest, I'd like to continue using semantic-release as it is really a streamlined workflow. Really, the only problems with it right now is how it's handling 0.y.z version bumps and their unyielding opinions on starting with 1.0.0. Other than that, if I don't find a good substitute for it in the end, I'd still be happy to use it moving forward.

TL;DR (for closing #8):

[Semantic] Versioning (as it is right now) on major version < 1 is a hellhole of a mess, but is currently leaning towards 0.y.z where y CAN have breaking changes, intentional or not; and where z can be any other change (additives, bugfixes, etc).

decanTyme commented 1 year ago

One actual solution to all this mess is to just use ~standard-version~ release-please for all versions <1.0.0, then migrate back to semantic-release once ready to move to 1.0.0. But that means some things must be done manually.

decanTyme commented 1 year ago

After some testing out release-please, its workflow finally makes sense. Suffice to say it is a godsend. It works like magic and can be configured with just these two:

bump-minor-pre-major: true
bump-patch-for-minor-pre-major: true

While it's not a complete automation (i.e. you still have to manually merge auto-PRs, which in some cases is a good thing), I imagine it might work in this case. It just makes consolidating together changes to a single release so much easier. Requires a little more configuration than semantic-release, especially if there are multiple release branches and pre-release branches (!).

There's also some limitation with using the default GITHUB_TOKEN secret ~that might be worth looking into~. Doesn't seem to work with it and you get an error (also seems to loop-retry forever), only a Personal Access Token works:

✔ Starting GitHub PR workflow...
✔ Successfully found branch HEAD sha "cdd6bb10593479d3d1694b13ed80a1c7234a22e1".
✖ Error when creating branch
✖ RequestError [HttpError]: Error creating Pull Request: Resource not accessible by integration
✔ Retry attempt #1...
    at /home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:16560:21
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async createBranch (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22042:26)
    at async branch (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22070:9)
    at async retry.retries (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22815:48)
    at async createPullRequest (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22815:24)
    at async /home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:85509:30
    at async GitHub.createPullRequest (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:86585:20)
    at async Manifest.createOrUpdatePullRequest (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:87114:32)
    at async Promise.all (index 0) {
  status: 403,
  response: {
    ...
    data: {
      message: 'Resource not accessible by integration',
      documentation_url: 'https://docs.github.com/rest/reference/git#create-a-reference'
    }
  },
  ...
}
...
✔ Retry attempt #2...
...

Note that fine-grained PATs don't work with GitHub's GraphQL API just yet.

~~One caveat~~ Two caveats are 1) it doesn't support signing commits, at least not yet but the foundation is there (https://github.com/googleapis/code-suggester/pull/442) and they're just waiting for an implementation from someone, I guess; and 2) prerelease branches are still pretty much in a "to be designed", RFC state (https://github.com/googleapis/release-please/issues/510#issuecomment-1020248692).

decanTyme commented 1 year ago

Alright, I've tested out much of release-please (excluding monorepo things). Will have to rebase most things now as I wanna get rid of existing tags and stuff from semantic-release. Hopefully, signing commits will be fully supported in the coming months (although it seems that the tags themselves are signed with GitHub’s verified signature).

decanTyme / chartjs-plugin-tailwindcss-colors

Release Automation #10