A CI runner and later an OKE worker must retrieve the same permits-api artifact that was pushed to OCIR. How is that artifact identified on pull?

Artifacts in OCIR are identified by the same fully qualified reference used at push: <registry-domain>/<tenancy-namespace>/<repository>:<version> (or the same path pinned by digest). A CI runner and an OKE worker retrieve the permits-api image with docker pull or a kubelet pull of that identical string. Consistency of the reference—not where the image was built—is what binds producers and consumers to one artifact across laptop, pipeline, and cluster.

The developer’s laptop hostname recorded at build time is irrelevant metadata and is not how registries address manifests or blobs. Searching Object Storage for a bucket matching the repository display name confuses object buckets with the distribution API OCIR implements; buckets do not replace repository pulls. The tenancy home region alone, without repository or tag, cannot select which image or version to pull and leaves the client without a concrete artifact name.

Exam caveat: if the tag is mutable, two pulls of the same name at different times can yield different digests—pin with digest when you need bit-for-bit identity for audits or incident rollback. Operational check: copy the image string from the successful CI push log into the Deployment image field (or a manual docker pull on a worker-equivalent host) and verify the resolved digest matches the digest shown for that tag in the OCIR Console before promoting the release.