Repository navigation
Conversation
b5da537 to
fc1b3ed
Compare
|
Claude finished @mbevc1's task in 3m 24s —— View job Follow-up review
|
dockerImages.get takes the image as a single path segment, so an image such as repo/team/app@sha256:... answered 404 and kept its digest-pinned name. The slashes in the image path are now sent as %2F.
…try API kosli snapshot cloud-run read a tag-pinned image's manifest from the registry's OCI Distribution endpoint, which Artifact Registry authorises with the same permission that pulls image layers. An inventory tool then needs a grant that can pull every image in the project. The digest now comes from the Artifact Registry API's tags.get, a metadata read, for *-docker.pkg.dev images and for the gcr.io hosts that Artifact Registry serves. The manifest read stays as the fallback when the API lookup fails, so callers holding only the pull permission keep their digests.
The help asked for roles/artifactregistry.reader, which can pull every image in the repository. Digest and tag resolution now go through metadata reads, so the help names the two permissions they need and says that gcr.io hosts are covered as well.
…ve-names --resolve-names skipped digest-pinned images on the gcr.io hosts because Container Registry had no reverse lookup. Artifact Registry serves those hosts now, through repositories named after the host, and its dockerImages.get answers for them. The digest-pinned parser shares the host mapping the digest lookup uses, so both directions cover the same hosts.
182a872 to
625e84b
Compare
Claude follow-up reviewPrevious findings: none found. There is no prior Claude review, review comment, or PR review on this PR (checked Diff scoping note: BEFORE=182a8728 and AFTER=625e84b6 have diverged histories (ahead_by 4, behind_by 4 — not a simple fast-forward, consistent with a force-push/rebase), so I fell back to gh pr diff and reviewed the full set of hunks introduced by this branch's four commits (7934a19, c0a2b1f, 4042a0c, 625e84b). New findings: none. I read through the artifactRegistryRepoFor refactor, the digestFromTag/manifest-fallback logic in registry.go, and the escaping fixes for nested image paths, and cross-checked them against the new table-driven tests in registry_test.go / registry_http_test.go — the edge cases (empty segments, too-few segments, unsupported hosts, GCR host mapping, nested parent/child/img paths) are covered and consistent with the implementation. No bugs, security issues, or regressions found in the changed lines. Note: I was unable to run go build/go test in this sandboxed session (commands required interactive approval that wasn't available), so this is a static read-through rather than a verified test run — worth confirming CI is green before merge. |
kosli snapshot cloud-runnow reads a tag-pinned image's digest from the Artifact Registry API, a metadata read, and keeps the registry manifest read as the fallback. The manifest read needs the permission that also pulls image layers, which an inventory tool such as Cloud Capture should not hold.--resolve-namesnow handles nested image paths andgcr.ioimages, so both lookups cover the same hosts.Existing setups keep their digests. The one visible change is behind
--resolve-names: digest-pinnedgcr.ioimages are now reported under their tag.Fixes #1376
Checklist
charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR