Fix npm release

[rezrah]

Summary

🚧 WIP

Fixing the library release to npm by using our Primer org workflow instead of a custom, local one.

What approach did you choose and why?

• Last two releases have failed
• I suspect they failed because the custom access token doesn't have the correct permission scopes for this repo, as described here.
• Using the proposed token should work because it works for other Primer libraries

What should reviewers focus on?

• We'll need to test in prod after merging by manually triggering the release. Added a command to do this via GitHub UI.

Contributor checklist:

• All new and existing CI checks pass
• Tests prove that the feature works and covers both happy and unhappy paths
• Any drop in coverage, breaking changes or regressions have been documented above
• All developer debugging and non-functional logging has been removed
• Related issues have been referenced in the PR description

Reviewer checklist:

• Check that pull request and proposed changes adhere to our contribution guidelines and code of conduct
• Check that tests prove the feature works and covers both happy and unhappy paths
• Check that there aren't other open Pull Requests for the same update/change
• Verify the design tokens changed in this PR are expected using the diffing results in this PR

[changeset-bot]

⚠️ No Changeset found

Latest commit: 35bf695

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Variables changed

No variables changed

[langermank]

Thank you 🙌

[camertron]

Thanks for looking into this @rezrah, but I'm hesitant to merge these changes. I just finished a bunch of work to move away from GPR_AUTH_TOKEN_SHARED in favor of a GitHub App. The trouble with GPR_AUTH_TOKEN_SHARED is that it will expire over time, whereas the tokens issued by an App are sort-lived and issued on an as-needed basis. I believe the problem @langermank ran into yesterday is due to data missing from a GitHub API response, not an issue with the access token or the permissions attached to it. I'm currently looking into a fix.

[rezrah]

Thanks for looking into this @rezrah, but I'm hesitant to merge these changes. I just finished a bunch of work to move away from GPR_AUTH_TOKEN_SHARED in favor of a GitHub App. The trouble with GPR_AUTH_TOKEN_SHARED is that it will expire over time, whereas the tokens issued by an App are sort-lived and issued on an as-needed basis. I believe the problem @langermank ran into yesterday is due to data missing from a GitHub API response, not an issue with the access token or the permissions attached to it. I'm currently looking into a fix.

Absolutely fine 👍. Will close this and allow you to investigate, as i'll be unable to look into it further until Monday now.

ran into yesterday is due to data missing from a GitHub API response

Inclined to agree with this, as it could be related to the commit history thing raised in the changeset support issue. Have you tried backing out this commit and seeing if that fixes anything?

[camertron]

@rezrah I see the same failure for both our release.yml and release_canary.yml workflows. The canary one doesn't even get an auth token 🤔 I haven't tried backing out the commit, but that's a good idea. Thanks!

[camertron]

Turns out this was caused by a git hash collision. I was able to fix things in the short term by reverting the offending commit, then reverting the revert. I've also submitted a PR to the changesets project to get this fixed long-term.