add pkg.pr.new

[Andarist]

This PR makes it possible to test PR builds in other repositories using this flow:
1.

pnpm add https://pkg.pr.new/changesets/action/@changesets/action@b4392ca -D

-      - uses: changesets/action@6016cc9a31082e9751df01b026d92cf17cad56d0
+      - uses: ./node_modules/@changesets/action

[changeset-bot]

⚠️ No Changeset found

Latest commit: b4392ca

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

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pkg-pr-new@​0.0.71

View full report

[bluwy]

How does this work so I can test the action in a workflow?

[beeequeue]

oh i thought this was the main repo.
i don't think publishing it to pkg.pr.new lets us use it in any new way, GH actions don't use npm registries.

we would need to set up a custom release flow that builds and pushes the results to a branch of some kind and use the branch's ref to test it

[pkg-pr-new]

pnpm add https://pkg.pr.new/changesets/action/@changesets/action@b4392ca -D

commit: b4392ca

[Andarist]

Sorry for pinging you guys for review a little bit prematurely. I was still testing things out and had to patch some smaller issues. I have now used the build from this PR successfully in my test repository and included usage instructions in the PR description here.

[bluwy]

Hmm I'd prefer if we can directly use the action with a sha/branch, without installing anything. It doesn't feel like a right fit to use pkg.pr.new here for actions.

[Andarist]

I know it's a little on the creative side of things. But at the same time, I feel like it's an easy setup that nicely externalizes those preview releases from changesets/action in a way that doesn't require sharing any write permissions to the repo with the workflow.

The current release-pr.ts is complex and I'm still not like 100% sure if it's 100% safe (for example, its previous version was suffering from potential timing attacks). The proposed alternative is nice but isn't automatic and has some usability implications for forks. I've also seen that for #625 you hand-rolled that release (or something ;p)... So, all in all, this one feels to me like the best out of all those different attempts at getting this working in the safest way possible.

[bluwy]

As one of the official repos that uses changesets for github actions (which i'm still surprised it's possible), I think we can do better setting this up though. People will be referencing our setup and it's a bit clunky or even not possible for them to copy. For example, this requires a git checkout and npm install to work. Some actions may not require that, or we might not even require them in the future if we split pack and publish.

So if we can make our preview release script more robust, that'll be best overall. The process should be easier than a npm publish and I can help thoroughly audit if our git commands are safe.