Repository navigation
docs(#3503): document RPM lockfile scope for UBI bump PRs #3575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
eb34197
547f362
709e1be
c2b0e7a
a4c363b
6ced835
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -112,6 +112,68 @@ Read these before modifying the corresponding areas: | |
| - [internal/validate/vsa/DESIGN.md](internal/validate/vsa/DESIGN.md) — VSA: storage backends, DSSE signing rationale, expiration model | ||
| - [acceptance/README.md](acceptance/README.md) — acceptance test framework, Testcontainers, WireMock, snapshot testing | ||
|
|
||
| ## UBI Base Image Updates | ||
|
jsmid1 marked this conversation as resolved.
|
||
|
|
||
| The project pins the `ubi-minimal` base image digest in three Dockerfiles: | ||
|
|
||
| - `Dockerfile` (production) | ||
| - `Dockerfile.dist` (distribution) | ||
| - `acceptance/kubernetes/kind/acceptance.Dockerfile` (acceptance tests) | ||
|
|
||
| The script `hack/ubi-base-image-bump.sh` updates all three files to the same | ||
| digest and then invokes `hack/update-rpm-lock.sh` to regenerate `rpms.lock.yaml`. | ||
| Renovate raises the same bump automatically; the script exists for manual runs | ||
| between Renovate PRs. All three Dockerfiles must pin the same digest, and the | ||
| lockfile must be regenerated after any digest bump. | ||
|
|
||
| ### RPM Lockfile Scope | ||
|
|
||
| `rpms.lock.yaml` is generated from `rpms.in.yaml`. It contains two kinds of | ||
| entries, and both are "tracked" for the purposes of this section: | ||
|
|
||
| 1. The packages explicitly listed in `rpms.in.yaml` — currently | ||
| `ca-certificates`, `jq`, and `gzip`. | ||
| 2. Their resolved transitive dependencies pulled in by the resolver | ||
| (for example `oniguruma`, which the lockfile carries as a dependency | ||
| of `jq`). These are not named in `rpms.in.yaml` but appear in | ||
| `rpms.lock.yaml` because the resolver had to pin them. | ||
|
|
||
| Together, "tracked packages" below means the union of (1) and (2): every RPM | ||
| that ends up in `rpms.lock.yaml`, whether requested directly or pulled in | ||
| transitively. | ||
|
|
||
| RPMs that ship inside the base image itself (for example `curl-minimal`, | ||
| `glib2`, `libcurl-minimal`, `libnghttp2`) are **not** tracked in the lockfile — | ||
| they are neither listed in `rpms.in.yaml` nor pulled in as a transitive | ||
| dependency of anything that is. | ||
|
|
||
| Consequence: when a UBI base image digest bump ships updates only to | ||
| base-image-bundled RPMs and no tracked package's available version changed | ||
| (neither an explicitly listed package nor any of its resolved transitive | ||
| dependencies), `hack/update-rpm-lock.sh` runs successfully but produces no | ||
| diff in `rpms.lock.yaml`. A commit that bumps the digest in the Dockerfiles | ||
| without touching `rpms.lock.yaml` is the expected outcome in that case, not | ||
| evidence that the lockfile was skipped. | ||
|
|
||
| ### Review Guidance for UBI Bump PRs | ||
|
|
||
| On any PR that bumps the `ubi-minimal` digest: | ||
|
|
||
| - Do **not** flag "`rpms.lock.yaml` was not regenerated" as a finding solely | ||
| because the lockfile is unchanged. Regeneration is a no-op when no tracked | ||
| package's version changed, and that is the common case. Confirm the lockfile | ||
| was regenerated only by asking the author (or checking CI logs) — the diff | ||
| alone cannot prove it either way. | ||
| - If the concern is that a new base-image-bundled RPM should be tracked | ||
| explicitly, that is a separate change to `rpms.in.yaml`, not a bug in the | ||
| bump PR. | ||
|
|
||
| On `release-v*` branches, bump PRs may intentionally update only the production | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [low] intent-coherence Issue #3503 proposed four documentation topics; the PR adds a fifth (release-branch nuance — bump PRs may intentionally skip the acceptance Dockerfile on release-v* branches) not enumerated in the issue but consistent with its stated goal ('prevent false-positive review findings') and plausibly a refinement of the 'reviewer guidance' topic. |
||
| Dockerfiles (`Dockerfile`, `Dockerfile.dist`) and skip the acceptance | ||
| Dockerfile, since acceptance test infrastructure is typically not backported. | ||
| The coordinated update set in `hack/ubi-base-image-bump.sh` applies to `main`; | ||
| a narrower scope on release branches is expected, not stale. | ||
|
|
||
| ## Claude Code Skills | ||
|
|
||
| Skills live in `.claude/skills/<name>/SKILL.md`. They are **step-by-step executable workflows** | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[low] intent-coherence
The PR body acknowledges that PR #3504 also adds a 'UBI Base Image Updates' section to AGENTS.md covering release-branch behavior. If both PRs land without pre-merge reconciliation, AGENTS.md will contain two sections with the same H2 heading. The PR author explicitly flags this and defers reconciliation.
Suggested fix: Coordinate with the author of PR #3504 to ensure whichever PR lands second is rebased and the sections merged. Git will surface a conflict naturally if both target the same region, so the risk is bounded.