docs(release): pull the candidate before scanning it - #793
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d1ca02a0b3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 47ce87898b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Renewing an image advisory fingerprint by hand followed the documented commands and still failed the gate, because Syft and Grype only report an image target's architecture and os from a daemon-backed provider. Scanned straight from the registry both fields come back empty and the gate rejects the evidence as not linux/amd64, which reads as an architecture mismatch on an image that is amd64. The candidate workflow never hits this: it runs the image to record --version before it scans, so the daemon already holds it. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The runbook fix documents that a scan is only admissible once the image has gone through the daemon, and notes the candidate workflow satisfies this incidentally by running the image for its --version first. Nothing held that ordering, so removing or reordering the run would reintroduce the same misleading linux/amd64 rejection on an amd64 image. Assert the run precedes both the Syft and the Grype scan. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The workflow-ordering test covers the candidate run but not the renewal snippet this change actually adds, so removing the documented pull left the operator path uncovered. Assert the snippet pulls the candidate before both scanners. Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
f2c4365 to
36b354a
Compare
1 participant
Found while renewing the three image advisory fingerprints for v0.23.0.
Following the documented renewal commands exactly still failed the gate.
check-advisory-baselines.pyrequires the scan report's image target todeclare
architecture: amd64andos: linux, but Syft and Grype onlypopulate those fields from a daemon-backed provider. Given a bare
registry reference on a machine that does not already hold the image,
both come back empty and the gate fails with:
which reads as an architecture mismatch on an image that is, in fact,
amd64. The real cause is the provider, not the platform.release-candidate.ymlnever hits this, but only incidentally: it runsthe candidate once to record its
--versionbefore scanning, so thedaemon already holds the image by the time Grype resolves the reference.
Nothing in the workflow states that the scan depends on that ordering.
This adds the missing
docker pullto the renewal snippet and says whyit is load-bearing rather than a convenience.
Verification
python3 -m unittest release/scripts/test_release_workflow_structure.py-> 37 tests OKpython3 -m unittest release/scripts/test_check_advisory_baselines.py-> 46 tests OKpython3 -m unittest release/scripts/test_registry_release.py-> OKpython3 -m unittest release/scripts/test_check_release_source_model.py-> 12 tests OKrelease/OPERATIONS.md:279is the only place in the tree that instructsan operator to scan a registry reference, so this is the only occurrence
to correct.