-
Notifications
You must be signed in to change notification settings - Fork 33
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
[BUG] Remote images take precedence over localhost images #66
Comments
Any updates on this? There should at least be some warning that the image name is ambiguous and Since this is open for about a year now, the workflow logs were deleted. Here's a new one: https://github.com/SGSGermany/debian/actions/runs/5062208592/jobs/9087436977#step:9:115 |
This is a aworkaround for https://github.com/redhat-actions/push-to-registry confusing the the just built image with the base image; see redhat-actions/push-to-registry#66
This is a workaround for https://github.com/redhat-actions/push-to-registry confusing the the just built image with the base image; see redhat-actions/push-to-registry#66
This is a workaround for https://github.com/redhat-actions/push-to-registry confusing the just built image with the base image; see redhat-actions/push-to-registry#66
This is a workaround for https://github.com/redhat-actions/push-to-registry confusing the just built image with the base image; see redhat-actions/push-to-registry#66
This is a workaround for https://github.com/redhat-actions/push-to-registry confusing the just built image with the base image; see redhat-actions/push-to-registry#66
I think I've had a similar issue in redhat-actions/buildah-build#129, which I "solved" via travier/quay-containerfiles@6378604. |
Version
redhat-actions/push-to-registry@v2
(pointing toredhat-actions/push-to-registry@v2.6
)Describe the bug
push-to-registry
currently does not support manually specifying the local image to push to the registry (also see #58, suggesting alocal
input). It rather uses the (unqualified) image name as reference. This will cause issues when Podman's registry search path (i.e. Podman's defaultregistries.conf
) doesn't resolve the unqualified image name to the local storage, but a registry.push-to-registry
might end up pushing the wrong image...Steps to reproduce, workflow links, screenshots
See https://github.com/SGSGermany/debian/runs/6995305321?check_suite_focus=true#step:8:113
Here I'm building a base image for Debian-based containers. The source is
docker.io/debian:bullseye
(digestsha256:ea4b2132c62e73f34156f416e5e21247b58f5cb4ab23105071ca94472f78d02d
) and the image built (digestsha256:9b831a98b2faed194c86234c8f4e9111eb38c44652530a40601b698056315453
) is tagged withdebian:bullseye
(among others, e.g.debian:v11
). I'm trying to push this image with all its tags toghcr.io/sgsgermany/debian
.As you can see,
push-to-registry
pushesdocker.io/debian:bullseye
for thebullseye
tag, and not the expectedlocalhost/debian:bullseye
(compare digests; digests of the pusheddebian:bullseye
anddebian:v11
don't match, even thoughlocalhost/debian:bullseye
andlocalhost/debian:v11
match).push-to-registry
should always use a fully-qualified image name for the local image (i.e./usr/bin/podman push --quiet --digestfile debian-v11.3_digest.txt localhost/debian:bullseye ghcr.io/sgsgermany/debian:bullseye --tls-verify=true
).Another solution might be to setCONTAINERS_REGISTRIES_CONF=/dev/null
forpodman push
, but this needs verification.The text was updated successfully, but these errors were encountered: