chore: recover from the Rekor 409 that keeps failing releases

.github/workflows/release.yml

@@ -11,6 +11,7 @@ on:
         options:
           - normal
           - canary
+          - from-package
       debug:
         description: "Verbose publish logs (needed to see Sigstore HTTP status codes)"
         required: false
@@ -59,6 +60,8 @@ jobs:
 
           if [ "${{ github.event.inputs.release_type }}" = "canary" ]; then
             npm run release-canary -- --yes "$@"
+          elif [ "${{ github.event.inputs.release_type }}" = "from-package" ]; then
+            npm run release-from-package -- --yes "$@"
           else
             npm run release -- --yes "$@"
           fi

RELEASING.md

@@ -1,6 +1,6 @@
 # Releasing
 
-Both releases go through the **Release** workflow
+Every release goes through the **Release** workflow
 (`.github/workflows/release.yml`), dispatched by hand with a release type. It
 runs the matching script below with `--yes`.
 
@@ -26,3 +26,16 @@ The preid carries a UTC timestamp (`--preid canary-$(date -u +%Y%m%d%H%M%S)`).
 Every other part of a canary version derives from the commit, so without it a
 second canary from the same commit regenerates a version already on npm and the
 publish fails. Keep it if you touch that script.
+
+## Recovering a partial release
+
+```bash
+npm run release-from-package
+```
+
+A normal release tags, commits and creates the GitHub releases before it
+publishes, so when a publish fails midway the failed packages are tagged but
+not on npm, and the next normal release sees nothing to bump for them. This
+publishes every package whose `package.json` version is missing from the
+registry, and nothing else. In the workflow, it is the `from-package` release
+type.

package.json

@@ -29,7 +29,8 @@
     "lint": "turbo run lint",
     "test": "turbo run test",
     "release": "npm run build && lerna publish --conventional-commits --create-release=github",
-    "release-canary": "npm run build && lerna publish --canary --force-publish --dist-tag canary --preid canary-$(date -u +%Y%m%d%H%M%S)"
+    "release-canary": "npm run build && lerna publish --canary --force-publish --dist-tag canary --preid canary-$(date -u +%Y%m%d%H%M%S)",
+    "release-from-package": "npm run build && lerna publish from-package"
   },
   "engines": {
     "node": "22"

patches/sigstore@4.1.1.patch

@@ -0,0 +1,13 @@
+diff --git a/dist/config.js b/dist/config.js
+index 373149fe22fb750faeefba5d20a0e432bb91df14..3e3173d504330cd385d84637e12a95eea9731e52 100644
+--- a/dist/config.js
++++ b/dist/config.js
+@@ -102,7 +102,7 @@ function initWitnesses(options) {
+         witnesses.push(new sign_1.RekorWitness({
+             rekorBaseURL: options.rekorURL,
+             entryType: options.legacyCompatibility ? 'intoto' : 'dsse',
+-            fetchOnConflict: false,
++            fetchOnConflict: true,
+             retry: options.retry ?? exports.DEFAULT_RETRY,
+             timeout: options.timeout ?? exports.DEFAULT_TIMEOUT,
+         }));

pnpm-workspace.yaml

@@ -46,3 +46,12 @@ overrides:
 minimumReleaseAge: 1440
 minimumReleaseAgeExclude:
   - "@argos-ci/*"
+
+patchedDependencies:
+  # Provenance publishing (lerna -> libnpmpublish -> sigstore). When a Rekor
+  # write commits but the 5s client timeout fires first, sigstore retries and
+  # Rekor answers 409 "an equivalent entry already exists". sigstore hardcodes
+  # `fetchOnConflict: false`, so that 409 kills the publish mid-release. The
+  # patch turns it on: on a 409, fetch the entry we already wrote and carry on.
+  # Drop once https://github.com/sigstore/sigstore-js/issues/1708 is fixed.
+  sigstore@4.1.1: patches/sigstore@4.1.1.patch