redhat-actions / push-to-registry Goto Github PK
View Code? Open in Web Editor NEWGitHub Action to push a container image to an image registry.
Home Page: https://github.com/marketplace/actions/push-to-registry
License: MIT License
GitHub Action to push a container image to an image registry.
Home Page: https://github.com/marketplace/actions/push-to-registry
License: MIT License
redhat-actions/push-to-registry@v2
(pointing to redhat-actions/[email protected]
)
push-to-registry
currently does not support manually specifying the local image to push to the registry (also see #58, suggesting a local
input). It rather uses the (unqualified) image name as reference. This will cause issues when Podman's registry search path (i.e. Podman's default registries.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...
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
(digest sha256:ea4b2132c62e73f34156f416e5e21247b58f5cb4ab23105071ca94472f78d02d
) and the image built (digest sha256:9b831a98b2faed194c86234c8f4e9111eb38c44652530a40601b698056315453
) is tagged with debian:bullseye
(among others, e.g. debian:v11
). I'm trying to push this image with all its tags to ghcr.io/sgsgermany/debian
.
As you can see, push-to-registry
pushes docker.io/debian:bullseye
for the bullseye
tag, and not the expected localhost/debian:bullseye
(compare digests; digests of the pushed debian:bullseye
and debian:v11
don't match, even though localhost/debian:bullseye
and localhost/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 set CONTAINERS_REGISTRIES_CONF=/dev/null
for podman push
, but this needs verification.
In the Manifest Push example qemu-user-static is installed using apt, and it appears quite old.
https://github.com/redhat-actions/push-to-registry/blob/main/.github/workflows/manifest-build-push.yaml#L39
WIth ppc64le it errors, at least with a UBI 9 container.
Fatal glibc error: CPU lacks float128 support (POWER 9 or later required)
error building at STEP "RUN make docker": error while running runtime: exit status 127
time="2023-02-01T18:30:27Z" level=error msg="exit status 127"
This looks to be an old issue with qemu.
https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg03526.html
I ended up using the docker setup-qemu-action action to install a newer qemu-user-static and it works fine. My questions is whether you have an alternate solution for getting a newer qemu-user-static and whether it's worth updating the example in either case.
The only other thing that caught me off guard was using ./ for the push step.
https://github.com/redhat-actions/push-to-registry/blob/main/.github/workflows/manifest-build-push.yaml#L64
Aside from those it wored great, than you!
redhat-actions/push-to-registry@v2
Action runs successfully but fails to push images (though it does push tags) to Quay.io registry.
Using this configuration:
- name: Build image
id: build-image
uses: redhat-actions/buildah-build@v2
with:
image: myimage
tags: latest ${{ github.sha }}
containerfiles: |
./Dockerfile
- name: Push to quay.io
id: push-to-quay
uses: redhat-actions/push-to-registry@v2
with:
image: ${{ steps.build-image.outputs.image }}
tags: ${{ steps.build-image.outputs.tags }}
registry: quay.io/myregistry
username: ${{ secrets.QUAY_USERNAME }}
password: ${{ secrets.QUAY_PASSWORD }}
which appears healthy (??), I noticed that the registry was receiving tags but no images on what appeared to be successful actions. Looking at the logs, the first silent error appears here after Checking if the given image is manifest or not.
:
/usr/bin/podman manifest exists myimage:latest /usr/bin/podman manifest exists myimage:latest Error: localhost/myimage:latest: image is not a manifest list
This error appears a few more times, then:
usr/bin/podman --root /tmp/podman-from-docker-Gff2z9 --storage-opt overlay.mount_program=/usr/bin/fuse-overlayfs pull docker-daemon:myimage:latest Error: initializing source docker-daemon:myimage:latest: loading image from docker engine: Error response from daemon: reference does not exist
I'm also seeing double log lines for every log in this run. Have I configured things incorrectly? It looks as close as I can make out to the basic tutorial case. Thanks.
The following scenario seems not to be supported as of yet:
Containerfile + artifacts in a build directory
.
├── build
│ ├── Containerfile
│ └── setup.sh
Containerfile copying artifact from the build directory
(...)
COPY setup.sh .
(...)
The current setup seems to only query the root directory, rather than the build directory:
error building at STEP "COPY setup.sh .": checking on sources under "/home/runner/work/<repo-name>/<repo-name>": copier: stat: "/setup.sh": no such file or directory
Add an option to set a build context directory
I can not use this action to sign a container with sigstore when pushing it.
Add an option to the GitHub Action to be able to pass a sigstore private key to use when pushing to sign the containers.
The cosign action does not let me push and sign a container in a single atomic step.
redhat-actions/push-to-registry@v2
If a user has uppercase letters in their github username they will get a transport error when uploading containers to ghcr
A copy of the error occurs here
https://github.com/TrevorDecker/push-to-registry/runs/7242515507?check_suite_focus=true#step:5:57
changing
IMAGE_REGISTRY: ghcr.io/${{ github.repository_owner }} to IMAGE_REGISTRY: ghcr.io/trevordecker fixes the problem
I've found myself wishing we still had the old behaviour which output a single registry path only. This was easier to pass to subsequent steps than parsing the json and selecting [0].
We can add back the old registry-path
output which just contains registry-paths[0]
. This has an added bonus of making v1 -> v2 migration easier.
Luckily I managed to figure out this issue, but I wanted to write about it so that other could find it.
In the step
using this action, I would receive the following error from Podman:
Error: trying to reuse blob sha256:b2d5eeeaba3a22b9b8aa97261957974a6bd65274ebd43e1d81d0a7b8b752b116 at destination: failed to read from destination repository my_org/my_image: 403 (Forbidden)
This was a pre-existing package that I'm simply trying to automate the workflow around. The solution lied in permissions on the package. Namely, I needed to:
Voila! It works now.
There's possibility that remote podman is used. For example wrapper for podman --remote
One possible scenario:
Action should check this scenario. For example, by running podman --remote version
, in case (podman --remote is wrapped) then the server is present.
Server: Podman Engine
Version: 4.9.3
...
So functions which use temporary local storage are not relevant createDockerPodmanImageStroage and invocations such as /runner/tools/bin/podman --root /tmp/podman-from-docker-4BGtIv pull ...
must omit this local storage.
Maybe can be an option to set remote: true
to use podman --remote
. It's not clear yet what is the optimal way to explicitly define operation mode or detection based approach.
Sometimes I may want to update multiple tags with one image. For example, I want to tag my image with the git SHA but also latest
, or a release tag.
I should be able to do this with one action call.
redhat-actions/push-to-registry@v2
Summary page for workflows utilizing this action report that this extension relies on set-output
which will be deprecated end of May 2023: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
We should have a test case that installs the very newest podman release so we can test it before it is added to the GitHub runners.
Ref: #42 (comment)
redhat-actions/buildah-build#22 but for podman push, in this action.
The action has already been tested by pushing docker/oci images to a Quay registry.
This needs to be tested with
We should support tokens as well as username/password.
Though it's tempting to keep using dockerhub and quay, GHCR should also have a front-and-center example on this project since it comes with so little effort when using Actions (no other account required).
Hi!
GitHub is deprecating support for node16, as per the warning
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: redhat-actions/buildah-build@v2, redhat-actions/push-to-registry@v2. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
I know I signed off on this behaviour previously but the more I see it in my workflows the less I like it:
Checking the docker storage and not finding the image is normal operation, and not an error so long as the image is in podman.
I would like it if we grouped this output or checked for this error specifically, so that a regular workflow didn't have "Error" so prominently displayed in it.
However if any error other than this one occurs, it should be obvious.
We are having our own runners and are trying to stay Docker-free. To still be able to run actions with containers we added a symlink from podman.sock
to docker.sock
and let podman run in daemon-mode.
However when a Docker socket is available, this action is looking if the image is available there and then pulling it, even if the tags are already available in podman storage, in our case pulling from podman to podman, which doesn't make any sense. To make it worse it's failing at the end because it adds a docker.io
prefix, which is not there.
IMHO this doesn't make much sense anyway, because if I want to push from Docker, I would use the Docker action and not this one.
It would be awesome if there was an option to disable everything Docker-related so it's pure podman.
None
Logs of the failing build, if podman is running in daemon-mode with docker.sock
:
Run redhat-actions/push-to-registry@v2
Creating temporary Podman image storage for pulling from Docker daemon
Overriding storage mount_program with "fuse-overlayfs" in environment
🔍 Checking if the given image is manifest or not.
/bin/podman version
/bin/podman manifest exists 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master
/bin/podman manifest exists 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b
🔍 Checking if "123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master, 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b" present in the local Podman image storage
/bin/podman image exists 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master
/bin/podman image exists 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b
Tags "123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master, 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b" found in Podman image storage
🔍 Checking if "123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master, 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b" present in the local Docker image storage
/bin/podman --root /tmp/podman-from-docker-G7H07Y --storage-opt overlay.mount_program=/bin/fuse-overlayfs pull docker-daemon:123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master
/bin/podman --root /tmp/podman-from-docker-G7H07Y --storage-opt overlay.mount_program=/bin/fuse-overlayfs pull docker-daemon:123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b
Tags "123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master, 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b" found in Docker image storage
/bin/podman image inspect 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master --format {{.Created}}
2022-08-08 15:08:53.272951074 +0000 UTC
/bin/podman --root /tmp/podman-from-docker-G7H07Y --storage-opt overlay.mount_program=/bin/fuse-overlayfs image inspect docker.io/123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master --format {{.Created}}
Error: inspecting object: docker.io/123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master: image not known
Removing temporary Podman image storage for pulling from Docker daemon
/bin/podman --root /tmp/podman-from-docker-G7H07Y --storage-opt overlay.mount_program=/bin/fuse-overlayfs rmi -a -f
Untagged: 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:8c11373cd846042242f2c2331a5fab779c2f439b
Untagged: 123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master
Deleted: 2801cef2b857fd65b480c4aea2215da8b6241a33f299cc1b08af1c631f58f1ab
Error: podman exited with code 125
Error: inspecting object: docker.io/123456789101.dkr.ecr.eu-west-1.amazonaws.com/example-project:master: image not known
When attempting to use this wonderful GH Action, I happened to be using a repository that is capitalized (OSCAL). Having a registry with a capitalized name breaks the builds with the errors below. It would be preferable to just lowercase the repo name.
Run redhat-actions/push-to-registry@v2
Creating temporary Podman image storage for pulling from Docker daemon
Warning: "fuse-overlayfs" is not found. Install it before running this action. For more detail see https://github.com/redhat-actions/buildah-build/issues/45
Combining image name "cli" and registry "ghcr.io/oscal-club/OSCAL" to form registry path "ghcr.io/oscal-club/OSCAL/cli"
🔍 Checking if "cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5, cli:issue-1008-publish-container-images, cli:latest" present in the local Podman image storage
/usr/bin/podman version
/usr/bin/podman image exists cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5
/usr/bin/podman image exists cli:issue-1008-publish-container-images
/usr/bin/podman image exists cli:latest
Tags "cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5, cli:issue-1008-publish-container-images, cli:latest" found in Podman image storage
🔍 Checking if "cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5, cli:issue-1008-publish-container-images, cli:latest" present in the local Docker image storage
/usr/bin/podman --root /tmp/podman-from-docker-zmfOHJ pull docker-daemon:cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5
/usr/bin/podman --root /tmp/podman-from-docker-zmfOHJ pull docker-daemon:cli:issue-1008-publish-container-images
/usr/bin/podman --root /tmp/podman-from-docker-zmfOHJ pull docker-daemon:cli:latest
Tag "cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5" was found in the Podman image storage, but not in the Docker image storage. The image(s) will be pushed from Podman image storage.
⏳ Pushing "cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5" to ghcr.io/oscal-club/OSCAL/cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5, ghcr.io/oscal-club/OSCAL/cli:issue-1008-publish-container-images, ghcr.io/oscal-club/OSCAL/cli:latest as "xee5ch"
/usr/bin/podman push --quiet --digestfile cli-77ec43e8f757473a1e51d6ae5fc89de392c0faf5_digest.txt cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5 ghcr.io/oscal-club/OSCAL/cli:77ec43e8f757473a1e51d6ae5fc89de392c0faf5 --tls-verify=true --creds=xee5ch:***
Error: invalid reference format: repository name must be lowercase
Removing temporary Podman image storage for pulling from Docker daemon
/usr/bin/podman --root /tmp/podman-from-docker-zmfOHJ rmi -a -f
Error: podman exited with code 125
Error: invalid reference format: repository name must be lowercase
Apparently this is part of the registry spec, so albeit it minor, I am surprised others do not want the action to decapitalize the repo and onwer name as well.
After troubleshooting this evening, I use shell commands in GitHub Actions to lowercase the image name in the files.
``
redhat-actions/push-to-registry@v2
When attempting to push, the action fails with error message like this:
Pushing "docker.io/library/committime-exporter" with tag "280f5dcf5d8ddc945923f8141603046d534d0f99" to "quay.io/pelorus" as ""
Combining image name "committime-exporter" and registry "quay.io/pelorus" to form registry path "quay.io/pelorus/committime-exporter"
/usr/bin/podman push --quiet --digestfile docker.io-library-committime-exporter-280f5dcf5d8ddc945923f8141603046d534d0f99_digest.txt docker.io/library/committime-exporter:280f5dcf5d8ddc945923f8141603046d534d0f99 quay.io/pelorus/committime-exporter:280f5dcf5d8ddc945923f8141603046d534d0f99 --tls-verify=true --creds=:***
Error: docker.io/library/committime-exporter:280f5dcf5d8ddc945923f8141603046d534d0f99: image not known
Error: podman exited with code 125
Error: docker.io/library/committime-exporter:280f5dcf5d8ddc945923f8141603046d534d0f99: image not known
It look like the same thing is happening in this repository as well.
See https://github.com/redhat-actions/push-to-registry/actions/runs/1035845452
There might be case when user provide /
in the image name.
Example: namespace/imageName
If above image is provided then the action will fail to push the image to registry (only valid when image is present in docker storage)
So, We should throw an error and fail the action right away, stating /
is not allowed in the image name
Ref: #37
Hi in some test I've used s2i-build + push-to registry in a selfhosted runner and I think there is a problem when you build the image for second time. What I saw in the source code is if there is no image in the podman registry, the action try to pull the image from the docker registry, thas works ok the first time because the s2i-build leaves the created image in the docker registry. The second time, s2i-build creates a new version of the image in the docker registry, but when the push-to-registry action get the images form de podman registry, the image already exist, so the push-to-registry push again the previous version of the image and not the new one. I' ve mitigated this runing "podman rmi name:tag" after the push.
redhat-actions/push-to-registry@v2
(which now references redhat-actions/[email protected]
by default)
Prior to #50 passing multiple tags caused the action to push all listed tags separately. Since v2.4 it rather assumes the first tag to be some sort of "primary" tag and pushes all following tags as aliases of this "primary" tag. It falsely assumes that all tags reference the same digest.
The input tags: foo bar
executed the following prior to #50:
podman push my-image:foo quay.io/my-user/my-image:foo
podman push my-image:bar quay.io/my-user/my-image:bar
Starting with v2.4
it executes the following:
podman push my-image:foo quay.io/my-user/my-image:foo
podman push my-image:foo quay.io/my-user/my-image:bar
This is a BC breaking change and silently broke my CI.
I'm not sure whether this was an intended change. In any case, v2.4
needs to be withdrawn. If it wasn't intended, it needs fixing. If it was intended, it needs to be released as v3
instead, because it includes BC-breaking changes (following https://semver.org).
If it was intended I'd like to suggest removing the requirement for all tags to exist locally (except the primary tag of course).
As we have new CRDA action now, I think it is useful for our CI checks to have CRDA scan step so that we can run vulnerabilities scan on dependencies updates.
Hi guys 👋
I'm just wrapping up my workflows with the new s2i action supporting multiple tags (redhat-actions/s2i-build#29) the image builds just fine with multiple tags, but when I try to push with the push-to-registry
action, the action fails when podman
should pull the image from the normal Docker context:
Run redhat-actions/push-to-registry@v2
with:
image: domstolene/ip-avgivelser
tags: 2.0.0-128 253b187
registry: ghcr.io
username: domstolene
password: ***
tls-verify: true
env:
APP_NAME: ip-avgivelser
JAR_NAME: ip-avgivelser-2.0.0.jar
VERSION: 2.0.0
IMAGE_TAG: test
JAR_TARGET_FOLDER: target/
BASE_IMAGE: registry.access.redhat.com/fuse7/fuse-java-openshift:1.2
IMAGE_PUSH_REPOSITORY: ghcr.io
OUTPUT_IMAGE: domstolene/ip-avgivelser
IMAGE_SHA_TAG: 253b187
Checking if "domstolene/ip-avgivelser" with tags "2.0.0-128, 253b187" is present in Podman image storage
/usr/bin/podman version
/usr/bin/podman image exists domstolene/ip-avgivelser:2.0.0-128
/usr/bin/podman image exists domstolene/ip-avgivelser:253b187
Checking if "domstolene/ip-avgivelser" with tags "2.0.0-128, 253b187" is present in Docker image storage
/usr/bin/podman pull docker-daemon:domstolene/ip-avgivelser:2.0.0-128
/usr/bin/podman pull docker-daemon:domstolene/ip-avgivelser:253b187
Tags "2.0.0-128, 253b187" of "domstolene/ip-avgivelser" found in Docker image storage
"docker.io/library/domstolene/ip-avgivelser" was found in the Docker image storage, but not in the Podman image storage. The image(s) will be pulled into Podman image storage, pushed, and then removed from the Podman image storage.
Pushing "docker.io/library/domstolene/ip-avgivelser" with tags "2.0.0-128, 253b187" to "ghcr.io" as "domstolene"
/usr/bin/podman push --quiet --digestfile docker.io-library-domstolene-ip-avgivelser-2.0.0-128_digest.txt docker.io/library/domstolene/ip-avgivelser:2.0.0-128 ghcr.io/domstolene/ip-avgivelser:2.0.0-128 --tls-verify=true --creds=domstolene:***
Error: unable to find 'docker.io/library/domstolene/ip-avgivelser:2.0.0-128' in local storage: no such image
Error: Error: podman exited with code 125
Error: unable to find 'docker.io/library/domstolene/ip-avgivelser:2.0.0-128' in local storage: no such image
Removing "docker.io/library/domstolene/ip-avgivelser" from the Podman image storage
/usr/bin/podman rmi docker.io/library/domstolene/ip-avgivelser:2.0.0-128
Error: 1 error occurred:
* unable to find 'docker.io/library/domstolene/ip-avgivelser:2.0.0-128' in local storage: no such image
(node:1860) UnhandledPromiseRejectionWarning: Error: podman exited with code 1
Error: 1 error occurred:
* unable to find 'docker.io/library/domstolene/ip-avgivelser:2.0.0-128' in local storage: no such image
As you can see,
Tags "2.0.0-128, 253b187" of "domstolene/ip-avgivelser" found in Docker image storage
"docker.io/library/domstolene/ip-avgivelser" was found in the Docker image storage
But it fails when trying to pull into Podman image storage.
The target registry is ghcr
, and I have tried building the image as ghcr/domstolene/ip-avgivelser
as well - same result.
What am I not getting here? 😅
I need to get the digest after push in order to be able to deploy the image based on digest rather than the tag.
An action setup of mine recently failed as podman got a 502 response when trying to push to a registry. i assume that this was a temporary issue on the server side. is there a recommended way how one should prevent such situations?
Pushing an image with more than one tag seems to result in the same image pushed with a different digest per pushed tag.
buildah-build
and push-to-registry
actiontags: unstable {{ github.sha }}
)I stumbled over this while working on some PRs for dohq/dockerhub_ratelimit_exporter
where I wanted to add an incremental build workflow and ultimately release workflow pushing a Container Image.
I tried pushing to both the new ghcr.io
(tried formats: docker and oci) as well as docker.io
(tried format: docker), both resulting in the image getting pushed successfully, but with 2 different digests for the two tags.
my Fork's inc-build
Workflow
the result on ghcr.io
The "2" tags in the screenshot are the result of the same inc-build => the same image.
Use the docker based alternative actions to build and push, as these don't seem to face this problem
level=warning msg="Failed to add podman to systemd sandbox cgroup:
exec: \"dbus-launch\": executable file not found in $PATH"
Of course we don't have dbus availble on GH runners, because they lack a desktop environment. We should figure out a way to suppress this error.
Some of the user may need to set tls-verify
to false.
N/A
I pulled the example from https://github.com/redhat-actions/push-to-registry#examples and tried to run in locally.
the tool I was using is https://github.com/nektos/act.
the local build failed
I would love to make this work locally as-well so I can build this GHA with confidence.
I am not sure the maintainer of act can help here, but we might want to add him in if need be
the failure I started with is:
act
...
[Build and Push Image/Build and push image] ❗ ::error::Error: Unable to locate executable file: buildah. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.
and after adding the section:
- name: Install Buildah
run: |
if ! $(which buildah 2>&1 >/dev/null); then
apt-get update
apt-get -y install buildah
fi
it fails on:
act
...
| E: Unable to locate package buildah
Hi, I've have a problem with the digest file name generated by the action If the name of the image include "/".
/usr/bin/podman push --quiet --digestfile poc-cicd/api_latest_digest.txt --creds openshift:*** poc-cicd/api:latest default-route-openshift-image-registry.com/poc-cicd/api:latest --tls-verify=false
Error: failed to write digest to file "poc-cicd/api_latest_digest.txt": open poc-cicd/api_latest_digest.txt: no such file or directory
Currently I have to do the following to know where my image ended up:
${{ env.IMAGE_REGISTRY }}/${{ env.QUAY_USER }}/${{ env.IMAGE_NAME }}:${{ env.IMAGE_TAG }}"
This should be an output from this action.
redhat-actions/push-to-registry@v2
The image name doesn't seem to correctly normalise. I used the example configs for GHCR, which uses the repository owner variable, but it doesn't convert the entire registry to lowercase. I ended up with an obscure error: unknown transport "ghcr.io/OrgExample/imagename"
Use IMAGE_REGISTRY: ghcr.io/${{ github.repository_owner }}
when using an org/username with capital letters in it.
Ref #57
v2.4
breaks pushing multiple tags by assuming that all tags reference the same digest (see #57). The first tag is assumed to be some sort of "primary" tag and all following tags are just "aliases". This apparently wasn't intended and needs fixing, but nevertheless, I actually like the idea - just not for a v2
release, but v3
.
I remember when using redhat-actions/push-to-registry
for the first time I actually assumed multiple tags to be aliases. This feels way more natural, especially when considering that the tags
input supports fully qualified image names. If we assume tags: foo quay.io/my-user/my-image:bar
as input I didn't expect that there needs to be a bar
tag locally. This (false) interpretation (of mine) also matches how we'd use podman push
: The first tag is the local tag (the first arg of podman push
), all following tags are remote tags (subsequent args of podman push
). Additionally, I don't really see a reason why we would expect the bar
tag to exist locally for inputs like quay.io/my-user/my-image:bar
. Anyhow, silently assuming the first tag to be the local one feels a bit hacky, too.
Thus I'd like to suggest to mimic podman push
. There should be a separate, but optional input for the local image name (let's call it local
). The existing registry
, image
and tags
inputs can be interpreted just as in the current v2.4
. The local
input defaults to the value of image
and the first tag in tags
- and only this tag is required to exist locally. If the first tag in tags
is a fully qualified image name, we bail (we shouldn't silently assume that a tag in a fully qualified image name exists locally).
I'd like to add that when using Buildah, images are commited with the latest
tag by default. This is totally fine in build environments. But we don't necessarily want to push this image with the latest
tag. Right now we have to add another step to our build scripts to additionally tag the digest with all the tags we want on our registry. IMO this is a superfluous step. By introducing a separate local
input we can spare this step.
This
registry: quay.io/my-user
image: my-image
tags: foo my-other-image:bar quay.io/my-other-user/yet-another-image:latest
executes (as in v2.4
)
podman push my-image:foo quay.io/my-user/my-image:foo
podman push my-image:foo quay.io/my-user/my-other-image:bar
podman push my-image:foo quay.io/my-other-user/yet-another-image:latest
This
tags: quay.io/my-user/my-image:foo quay.io/my-user/my-other-image:bar quay.io/my-other-user/yet-another-image:latest
results in a "no local tag to push given" error (we don't silently assume the tag of a fully qualified image name to exist locally).
This
local: working-image:latest
registry: quay.io/my-user
image: my-image
tags: foo my-other-image:bar quay.io/my-other-user/yet-another-image:latest
executes
podman push working-image:latest quay.io/my-user/my-image:foo
podman push working-image:latest quay.io/my-user/my-other-image:bar
podman push working-image:latest quay.io/my-other-user/yet-another-image:latest
This
local: working-image:latest
tags: quay.io/my-user/my-image:foo quay.io/my-user/my-other-image:bar quay.io/my-other-user/yet-another-image:latest
executes
podman push working-image:latest quay.io/my-user/my-image:foo
podman push working-image:latest quay.io/my-user/my-other-image:bar
podman push working-image:latest quay.io/my-other-user/yet-another-image:latest
Add feature to push manifest.
redhat-actions/push-to-registry@v2
Running the action shows:
(node:19061) [DEP0147] DeprecationWarning: In future versions of Node.js, fs.rmdir(path, { recursive: true }) will be removed. Use fs.rm(path, { recursive: true }) instead
(Use `node --trace-deprecation ...` to show where the warning was created)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.