Skip the Hermes build when the archive is already published

[kraenhansen]

Merging #443 kicked off run 31724154546, which set about rebuilding — for half an hour — the archive that had been published 25 minutes earlier, to then re-upload 118 MB byte-for-byte equivalent to what was already there. I cancelled it.

What did and didn't guard this

The paths: filter works. The workflow does not fire on every merge to next — only on edits to hermes.ts, hermes-prebuilt.ts or the workflow itself. But that still means any unrelated edit to those files (a comment, a refactor, a new CLI flag) pays for a full rebuild, and #443 was exactly that.

The Actions cache does not cover it, for two reasons worth writing down:

• It is scoped to the branch that wrote it. The successful build ran on Stop the host Hermes compiler build from targeting visionOS #443's branch, so the cache it saved was never visible to next — and disappeared with the branch.
• Even on the default branch it evicts after 7 days idle, or under the repository's 10 GB cap, which the test-ios (3 GB) and other ccache entries already compete for.

--no-download deliberately bypassed the one authoritative signal — the published asset itself. That flag exists so a forced rebuild doesn't round-trip the asset it is about to replace, which is still right; it just needed a decision made before it.

The change

The archive name already covers every input that changes its contents — pinned commit, React Native version, build type, platforms, host architecture. So an asset published under that name is the archive this run would produce. A new step looks it up with gh release view --json assets and, when it is there, skips the cache restore, the build and the upload.

workflow_dispatch gains a force input for deliberate rebuilds — a corrupted upload, or a toolchain change that alters the output without changing the name.

Cost when the asset exists: checkout, install, build, two --print calls and one API lookup. About a minute, versus thirty.

Known gap, not addressed here

A React Native bump changes the archive name but touches none of the paths in the filter, so no asset gets published for the new version until someone dispatches manually — CI and consumers fall back to building locally, correctly but slowly. Adding pnpm-lock.yaml to paths: would close it, and with this gate in place the cost is a one-minute no-op run per dependency bump. Left out because it widens the trigger noticeably; say the word and it is a one-line follow-up.

Test plan

• Dispatched on this branch: Look for an already-published archive reports exists=true, the build and publish steps skip, and the run finishes in about a minute
• A dispatch with force: true still rebuilds

---

Generated by Claude Code