Hey there! I'm one of the maintainers over at Svelte.

The below is as thorough an explanation / request as I could manage. If you agree with this plan, I'd be happy to open a PR for it, and also happy to discuss.

Problem

When using pkg-pr-new from a workflow_dispatch trigger (e.g. to build a fork PR's commit), the published package is tagged with the wrong SHA.

This happens because:

1. A maintainer triggers workflow_dispatch on main, passing a fork commit SHA as an input.
2. actions/checkout correctly checks out the fork commit.
3. GitHub fires a workflow_run webhook with head_sha set to the tip of main (not the fork commit), because that's what workflow_dispatch does.
4. The pkg.pr.new server stores this head_sha as the SHA for the run (webhook.post.ts:61).
5. The CLI fetches the SHA from /check and uses it for all URLs.
6. The package tarball is stored under the wrong SHA key (publish.post.ts:113).

The result: pkg.pr.new/svelte@<tip-of-main-commit> contains the correctly-built fork code, but is filed under main's tip hash. pkg.pr.new/svelte@<actual-fork-sha> doesn't exist.

This is a common pattern for repos that use pull_request_target for same-repo PRs but workflow_dispatch for fork PRs (to avoid blindly publishing untrusted code).

Proposed solution

Allow the CLI to pass an optional SHA override that the server uses instead of workflowData.sha for the storage key and URL generation.

For example:

• CLI: A new --sha <hash> flag, sent as an sb-sha header on the /publish request.
• Server (publish.post.ts): If sb-sha is present, use it instead of workflowData.sha for the package storage key and all generated URLs.

This is safe because the request is already authenticated via the workflow run key. The SHA only affects where the tarball is stored — it doesn't grant any extra privilege. The server could optionally validate the override SHA is a real commit in the repo.

Context

We hit this in the sveltejs/svelte repo: https://github.com/sveltejs/svelte/actions/runs/22244600007

The debug output from that run confirms the issue:

{
  "workflowData": {
    "sha": "0c7f815143c878d4c2819e45e5f2992da1209f63",
    "ref": "main"
  }
}

...where 0c7f815 is the tip of main, not the fork commit (75c39e5) that was actually checked out and built.