The publish-github-container-registry job's Generate artifact attestation step succeeds but emits two warning annotations on every release, and they are the only annotations on an otherwise-green release run. From 2.5.0's run:
##[warning]Failed to create storage record: Error: Failed to persist storage record: no artifacts found - https://docs.github.com/rest/orgs/artifact-metadata#create-artifact-metadata-storage-record
##[warning]Please check that the "artifact-metadata:write" permission has been included
What is and isn't affected
The attestation itself is fine. The same step log shows it signed, logged and published through every channel:
Attestation type: Build Provenance
Attestation created for ghcr.io/modelcontextprotocol/inspector@sha256:cc589d70…
Attestation signed using certificate from Public Good Sigstore instance
Attestation signature uploaded to Rekor transparency log (logIndex=2688270384)
Attestation uploaded to repository → /attestations/44772895
Attestation uploaded to registry
and consumer-side verification of the published image passes:
gh attestation verify oci://ghcr.io/modelcontextprotocol/inspector:2.5.0 \
--repo modelcontextprotocol/inspector # exit 0
(A deliberately wrong --repo exits 1, so the exit-0 is a real pass rather than a no-op.)
What is not landing is the newer artifact-metadata storage record — GitHub's separate index of published artifacts, which actions/attest-build-provenance now also tries to write. That's a metadata row, not the provenance itself.
Why it's worth fixing anyway
- It is noise on every release, in the one channel where a release-job annotation should mean something. Same argument as Lint has no warning tier: a channel nobody fails on is one people learn to skim, and the real warning added later lands where everyone has learned to look past.
- The warning text names a plausible cause we can just satisfy, so leaving it is choosing to carry an unexplained warning rather than a one-line permission.
Suggested fix
The job already declares attestations: write (the log's GITHUB_TOKEN Permissions group confirms it). Add the newer scope alongside it in .github/workflows/main.yml:
publish-github-container-registry:
permissions:
contents: read
packages: write
attestations: write
artifact-metadata: write # ← storage record for the build provenance
id-token: write⚠️ Two things to confirm rather than assume:
- Whether the scope is actually available to this runner/token. If
artifact-metadata is not a recognized permission key, the workflow fails to parse — validate on a branch before a release rides on it.
- Whether the second warning is even the cause of the first.
no artifacts found may be about the job uploading no workflow artifact (this job builds and pushes an image; it produces only the *.dockerbuild record), in which case the permission changes nothing and the right outcome is to document the warning as expected rather than chase it. Establish which it is first — the fix is only a fix if the record actually appears afterwards.
Note the sibling npm publish job does not emit these warnings; only the GHCR job does.
Acceptance
- A release run's
publish-github-container-registry job is annotation-free, or .github/workflows/main.yml carries a comment on that step explaining why the warning is expected and cannot be cleared.
gh attestation verify oci://ghcr.io/modelcontextprotocol/inspector:<version> still passes afterwards.
Found while smoke-testing the 2.5.0 GHCR image (image itself verified good on both linux/amd64 and linux/arm64: web, CLI and TUI modes, auth gate, sandbox port, volume-backed secret store, and a browser end-to-end tool call all pass).
The
publish-github-container-registryjob's Generate artifact attestation step succeeds but emits two warning annotations on every release, and they are the only annotations on an otherwise-green release run. From 2.5.0's run:What is and isn't affected
The attestation itself is fine. The same step log shows it signed, logged and published through every channel:
and consumer-side verification of the published image passes:
gh attestation verify oci://ghcr.io/modelcontextprotocol/inspector:2.5.0 \ --repo modelcontextprotocol/inspector # exit 0(A deliberately wrong
--repoexits 1, so the exit-0 is a real pass rather than a no-op.)What is not landing is the newer artifact-metadata storage record — GitHub's separate index of published artifacts, which
actions/attest-build-provenancenow also tries to write. That's a metadata row, not the provenance itself.Why it's worth fixing anyway
Suggested fix
The job already declares
attestations: write(the log'sGITHUB_TOKEN Permissionsgroup confirms it). Add the newer scope alongside it in.github/workflows/main.yml:artifact-metadatais not a recognized permission key, the workflow fails to parse — validate on a branch before a release rides on it.no artifacts foundmay be about the job uploading no workflow artifact (this job builds and pushes an image; it produces only the*.dockerbuildrecord), in which case the permission changes nothing and the right outcome is to document the warning as expected rather than chase it. Establish which it is first — the fix is only a fix if the record actually appears afterwards.Note the sibling npm
publishjob does not emit these warnings; only the GHCR job does.Acceptance
publish-github-container-registryjob is annotation-free, or.github/workflows/main.ymlcarries a comment on that step explaining why the warning is expected and cannot be cleared.gh attestation verify oci://ghcr.io/modelcontextprotocol/inspector:<version>still passes afterwards.Found while smoke-testing the 2.5.0 GHCR image (image itself verified good on both
linux/amd64andlinux/arm64: web, CLI and TUI modes, auth gate, sandbox port, volume-backed secret store, and a browser end-to-end tool call all pass).