Two gaps in the "Prerequisites" section of release/OPERATIONS.md each cost the
v0.24.0 cycle a full candidate run. Both are in the new-image-package bootstrap
path, which discovery exercised for the first time.
1. The oras push snippet passes an absolute path
release/OPERATIONS.md builds bootstrap_dir with mktemp -d and then pushes:
"${bootstrap_dir}/bootstrap.txt:text/plain"
oras 1.3.x rejects an absolute file path in a file reference outright, so the
documented command cannot succeed as written. The fix is to push from inside the
directory so the reference is relative, for example cd "${bootstrap_dir}" before
the push and reference bootstrap.txt:text/plain.
2. Nothing says the -candidate package must be private, or how it becomes public
The prerequisites cover the final package (relay, evidence, mint,
discovery): bootstrap it, make it public, grant Actions write, verify with
gh api /orgs/registrystack/packages/container/<name>.
They say nothing about the <name>-candidate package, which must be private.
release-candidate.yml fails at "Publish exact layouts to private candidate
packages" if it is not. That is exactly how candidate run 1 failed for v0.24.0.
The underlying rule is not obvious and is worth stating: a package first
published by a classic PAT defaults to private, but a package first published
by Actions inherits the visibility of the repository, which is public here.
So whether <name>-candidate starts private depends on which mechanism created
it.
Suggested addition, alongside the existing four-package public check:
for package in relay-candidate evidence-candidate mint-candidate discovery-candidate; do
gh api "/orgs/registrystack/packages/container/${package}" \
--jq '[.name,.visibility]' 2>/dev/null || echo "[\"${package}\",\"absent\"]"
done
Each must report private or be absent. There is no REST endpoint for changing
package visibility, so a package that reports public has to be corrected in the
organization package settings UI before dispatch.
Already fixed, recorded here for completeness
The third gap found in the same cycle, that the renewal procedure omitted the
live pins in release/scripts/test_check_advisory_baselines.py, was fixed in
tree by #805 and needs nothing further.
Two gaps in the "Prerequisites" section of
release/OPERATIONS.mdeach cost thev0.24.0 cycle a full candidate run. Both are in the new-image-package bootstrap
path, which
discoveryexercised for the first time.1. The
oras pushsnippet passes an absolute pathrelease/OPERATIONS.mdbuildsbootstrap_dirwithmktemp -dand then pushes:"${bootstrap_dir}/bootstrap.txt:text/plain"oras 1.3.x rejects an absolute file path in a file reference outright, so the
documented command cannot succeed as written. The fix is to push from inside the
directory so the reference is relative, for example
cd "${bootstrap_dir}"beforethe push and reference
bootstrap.txt:text/plain.2. Nothing says the
-candidatepackage must be private, or how it becomes publicThe prerequisites cover the final package (
relay,evidence,mint,discovery): bootstrap it, make it public, grant Actions write, verify withgh api /orgs/registrystack/packages/container/<name>.They say nothing about the
<name>-candidatepackage, which must be private.release-candidate.ymlfails at "Publish exact layouts to private candidatepackages" if it is not. That is exactly how candidate run 1 failed for v0.24.0.
The underlying rule is not obvious and is worth stating: a package first
published by a classic PAT defaults to private, but a package first published
by Actions inherits the visibility of the repository, which is public here.
So whether
<name>-candidatestarts private depends on which mechanism createdit.
Suggested addition, alongside the existing four-package public check:
Each must report
privateor be absent. There is no REST endpoint for changingpackage visibility, so a package that reports
publichas to be corrected in theorganization package settings UI before dispatch.
Already fixed, recorded here for completeness
The third gap found in the same cycle, that the renewal procedure omitted the
live pins in
release/scripts/test_check_advisory_baselines.py, was fixed intree by #805 and needs nothing further.