Use new pr-release prerelease hook (Fixes #2987)

[JAForbes]

Description

Per @dead-claudia's suggestion, pr-release now allows you to invoke a custom command before creating the github release. If the command fails the process exits with a non zero code and the github release is never created.

Motivation and Context

This makes it clear that if a github release is created a corresponding npm release with the same tag also exists.

Note I haven't documented this feature as I'm improving documentation and making internal upgrades on another branch.

How Has This Been Tested?

• Created a test private repo and going through the pr/merge cycle a few times in CI and with the local debugger.
• Deployed pr-release itself using the same process --prerelease="npm publish" (CI, npm, github release)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My change requires a documentation update, and I've opened a pull request to update it already:
• I have read https://mithril.js.org/contributing.html.

[dead-claudia]

@JAForbes Have you confirmed it fails to invoke that when not given perms to create a release?

[JAForbes]

No, it doesn't check perms of the token. That's a good idea.

Do you want to wait for that before merging this or should I make that a separate PR? This change is already well tested and decreases risk for one of the two failure cases.

[JAForbes]

@dead-claudia had a look, seems there's no API available to decode PAT's to verify specific scopes. But if I query a repo with the token there's a permissions object:

"permissions": {
    "admin": true,
    "maintain": true,
    "push": true,
    "triage": true,
    "pull": true
  },

Which we can cross reference with their roles table:

But I think (but haven't verified) that permissions object will not be present for github app tokens as app tokens don't have roles, they just have scopes. I think the this endpoint will work for a github app token, but I'd rather cross that bridge in the future as I'm planning to make pr-release a github app, so it will be natural to test that more thoroughly then.

So I think a reasonable compromise for now would be, if the permissions hash is present and there's insufficient permissions, pr-release early exits non zero. If its not present it just pushes on for now. Does that seem okay to you? If so I'll kick that off.

[dead-claudia]

@JAForbes You may be able to get away with splitting the release into two steps: create draft release, do prerelease step, publish release.

Draft releases require the same perms as fully published releases. Only difference is it's not actually published.

[JAForbes]

Great idea, might do both actually

[dead-claudia]

Separately, after this PR, I'd like to modify the workflow to create an automated issue if the publish step fails for any reason.

[JAForbes]

@dead-claudia it now detects insufficient permissions and exits early and creates a draft release and only finalizes the release after running the --prerelease hook (npm publish in our case).

For the negative case I tested against https://github.com/JohnForbes/pr-release-test-repo-4 (which I have contrib access to but not admin) and for the positive case I just released a new version of pr-release using the new changes.