Skip to content
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

Using push_only option causes the job to fail #46

Closed
jwickham-patchfox opened this issue Dec 21, 2023 · 4 comments
Closed

Using push_only option causes the job to fail #46

jwickham-patchfox opened this issue Dec 21, 2023 · 4 comments

Comments

@jwickham-patchfox
Copy link

I'm configuring an action to push an image built by a previous step and consequently am using the push_only option. However, this seems to cause the build to fail. Can you provide some guidance or verify that this is broken please?

action.yaml:

steps:
  - id: google_auth
    uses: google-github-actions/auth@v1
  - id: build-app
    run: # do the build step, resulting in an image
  - id: google-upload
    name: Upload image to Google Registry
    uses: RafikFarhad/push-to-gcr-github-action@v5-beta
    with:
      registry: ${{ env.REGISTRY_URL }}
      project_id: ${{ env.PROJECT_ID }}
      image_name: ${{ env.IMAGE_NAME }}
      image_tag: ${{ env.IMAGES_STRING }}
      push_only: true

output:

... (omitted for brevity)
Authentication successful to [.... registry]...
Skipping image build ...
Fully qualified image name: [.....]myimage:develop
Creating docker tag ...
Error response from daemon: No such image: [.....]myimage:temporary
Pushing image [.....]myimage:develop ...
The push refers to repository [.....]myimage
tag does not exist: [.....]myimage:develop
Pushing failed. Exiting ...

Reading the logs and the entrypoint.sh code, I believe what is happening is the TEMP_IMAGE_NAME is set to IMAGE_NAME:temporary (note the temporary tag), then later in the loop over image tags, and the code creates the fully qualified image name with the specified image tag (e.g. develop or latest, whatever is configured in image_tag in the yaml). After this, we get

docker tag $TEMP_IMAGE_NAME $IMAGE_NAME

which clearly is attempting to take the temp image which would have been built had I built it and create a new tag from it. However, since the build step didn't happen, it's attempting to create a new image tag from a nonexistent image (the one with :temporary), thus the attempt to create the :develop tag fails (this is the Error response from daemon: no such image: [.....]myimage:temporary line above). Since that fails, when it tries to push the :develop image, that image doesn't exist, causing the tag does not exist error.

Ideally, if doing a push-only solution, the TEMP_IMAGE_NAME wouldn't be used since we're not building a temporary image.

If I'm using this incorrectly, can you please provide more detailed instructions on how to build an image in a previous step and then upload it here?

Thanks much!

@jwickham-patchfox
Copy link
Author

I found a workaround, but I don't think it's elegant, and I feel like the action could be improved to avoid this step.

Before running this step, use docker tag to create a new tag from whatever image you emitted, but using the format {baseImageTag}:temporary. Don't include the registry host or the project id; those are part of the fully qualified image name. Thus, if you generated gcr.io/my_project_name/my_image_name:latest in your previous step, you'd want to execute this action:

      - id: retag
        name: New tag of Jib build for future use
        run: |
          docker tag gcr.io/my_project_name/my_image_name:latest my_image_name:temporary

Ideally, you could just build the image and name it properly in the same step. However, there are other actions which are rather rigid in their naming conventions. As an example (and how I encountered it), Jib creates the images with fully-qualified names, not just the image name. Thus, introducing a step like this is needed.

If it is a requirement that the image be named in a particular way, at minimum that could be in the documentation.

@RafikFarhad
Copy link
Owner

Thanks @jwickham-patchfox for reporting this.
I already started working on this and raised #47.
Your suggestions make sense, and I look forward to implementing these suggestions.

@jwickham-patchfox
Copy link
Author

okay, awesome thank you! I'll take a look

@RafikFarhad
Copy link
Owner

@jwickham-patchfox Just tested and released v5-rc1. Let me know if you face this issue anymore.
And thanks again for using this and for the contribution to making it better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants