Provide a publish command hook, to ensure that no release is actually created if either the push or the publish fail

[dead-claudia]

Related: MithrilJS/mithril.js#2987

TL;DR: I'm running into pain with releases being cut prematurely if it fails to successfully be published. Ideally, we'd be following this flow, aborting the whole process if any step fails:

1. Bump version, commit, and create new tag per pr-release.
2. Push new tag per pr-release.
3. Push (in our case, force-push) release branch.
4. Do npm publish.
5. Finally, create a release on GitHub.

Unfortunately, the current design of pr-release forces us into this flow:

1. Bump version, commit, and create new tag per pr-release.
2. Push new tag per pr-release.
3. Create a release on GitHub.
4. Push (in our case, force-push) release branch.
5. Do npm publish.

1 through 3 are wrapped up into a single command, so we can't move the release creation to after the npm publish without moving the version bump ahead of it as well. And moving the version bump ahead of the publish means the version isn't bumped before publishing, and this will obviously cause the npm publish to fail due to the version already existing.

[JAForbes]

It's interesting. I tend to think of the release on github being pr-release's job, and then publishing to registry's is out of scope. We've got jsr, npm, github registry etc and I always planned to use pr-release outside of the js ecosystem too eventually.

So wading into package registries is something I'd like to avoid.

Would it help if there was the ability to split writing to changelog, creating a tag etc and creating the github release?

# bump version, commit, new tag, update changelog but no github release
- run: npx pr-release start

- run: ...whatever you like...
- run: npm publish

# create the github release
- run
- run: npx pr-release complete

[dead-claudia]

@JAForbes Anything that can allow me to achieve the desired flow is sufficient. Though, splitting it up could probably have its own advantages in some production environments.

I'm just trying to avoid running into this deployment issue in the future.

[JAForbes]

TL;DR: I'm running into pain with releases being cut prematurely if it fails to successfully be published

Thinking about this I'm not sure where the abstraction boundary begins and ends. We're performing a series of side effects any one could fail. Any git command, any github api call, any npm publish etc. We can't make this an atomic transaction. pr-release is doing its job by managing the git/github/semver version, then (from what I understand) another separate script is failing which prevent the publish from running.

pr-release makes these changes in order of locality, first small changes like git commits, git tags, then larger changes like github releases, finally you can run a publish after pr-release has finished its work.

If pr-release was to do everything except create the github release, then you could have a similar situation where the git history is updated but there's no corresponding github release. So the original problem would become:

TL;DR: I'm running into pain with git commits occurring without a github release being created

So alternatively we could not touch the git history / github API / npm but instead output a representation of the changes we want to perform (kind of like a terraform plan), and then we have an apply command that runs after your custom commands (like a terraform apply), but that apply` could still fail.

There's no clear point in the series of effects to draw a line between a destructive / non-destructive change.

So I feel like (unless if I'm missing something) the fix here is in the mithril repo, not in pr-release. That second script set-versioned-branch.sh is failing because of a force branch failing permissions for that repo, in turn the publish never happens.

So either adjust the permissions, or adjust the branching strategy, or publish before the force push. Each has trade offs, but all feel separate to what pr-release does.

I also commented on the mithril issue, as I'm not sure why set-versioned-branch.sh is needed, but I guess we can pick up that discussion over there.

Let me know if I'm missing something.

[dead-claudia]

So I feel like (unless if I'm missing something) the fix here is in the mithril repo, not in pr-release. That second script set-versioned-branch.sh is failing because of a force branch failing permissions for that repo, in turn the publish never happens.

The root cause was a bug in the script setup, yes. But the reason I'm filing this issue is because I have no way to ensure that errors result in a least destructive state.

• If the push fails, I want to not publish or create the release.
• If the npm publish fails, I want to not create the release.

There's no clear point in the series of effects to draw a line between a destructive / non-destructive change.

How I view it is there are three types of destructive changes:

• Pushing to the repo
  • This destroys the old ref, but its destruction in my case can be repaired by a few Git commands.
• Creating a GH release
  • The destruction in this is in human and computer time of addressing the notification. There is no undo button here.
• Deploying to npm
  • The destruction is in using up a version, since packages cannot be deprecated. There is no undo button here.

We can talk about issues about that script in the Mithril.js issue, but this feature request stands regardless of it. It's not about avoiding the relevant errors, but about limiting their blast radius.

[JAForbes]

If the push fails, I want to not publish or create the release.

This part is already handled by pr-release if you let it perform the force push.

If the npm publish fails, I want to not create the release.

Given you've said you'd be okay with manually repairing a git history, then yeah we could address this with a prerelease hook. But I still feel its a lot clearer to treat pushing to registries as a distinct post release step but I guess that is a call a repo maintainer can make on a case by case basis.

[JAForbes]

@dead-claudia thanks for the feedback, I've opened a PR against the mithril repo. I'll close this off for now but note I'm planning to add / support lifecycle hooks generally and this is more of a stop gap to unblock mithril specifically.

[dead-claudia]

PR for future reference: MithrilJS/mithril.js#2996