circleci-public / gcp-gcr-orb

Orb for interacting with Google Container Registry from within a CircleCI build job

GCP GCR Orb

Orb for interacting with Google Container Registry on CircleCI.

Usage

For full usage guidelines, see the orb registry listing.

Contributing

We welcome issues to and pull requests against this repository!

For further questions/comments about this or other orbs, visit CircleCI's orbs discussion forum.

How To Contribute

We welcome issues to and pull requests against this repository!

To publish a new production version:

• Create a PR to the Alpha branch with your changes. This will act as a "staging" branch.
• When ready to publish a new production version, create a PR from Alpha to master. The Git Subject should include [semver:patch|minor|release|skip] to indicate the type of release.
• On merge, the release will be published to the orb registry automatically.

For further questions/comments about this or other orbs, visit the Orb Category of CircleCI Discuss.

gcp-gcr-orb's Issues

Remove dependency on circleci user

I tried to use this orb with the google/cloud-sdk image but it doesn't have the circleci user which makes chown fail:

gcp-gcr-orb/src/@orb.yml

Line 69 in aeaf1c7

$SUDO chown circleci:circleci /home/circleci/.docker -R

My quick fix is to add the circleci user:

      - run: useradd circleci

I think it would be better to make use of $USER and $HOME.

Artifact Registry Push Docker Images

I understand this orb is used for pushing the images to Container Registry . Can we use this for pushing Artifact Registry as well ?

gcloud-cli install taking 50+ seconds every build

Orb version

gcp-gcr: circleci/[email protected]

Although I have slightly modified the job from this orb in order to load the workspace for docker build. So I based my job on build-and-push-image and has the following steps:

    steps:
      - checkout
      - gcp-gcr/gcr-auth:
          google-project-id: <<parameters.google-project-id>>
          google-compute-zone: <<parameters.google-compute-zone>>
          gcloud-service-key: <<parameters.gcloud-service-key>>
      - attach_workspace:
          at: /tmp/workspace
      - gcp-gcr/build-image:
          registry-url: <<parameters.registry-url>>
          google-project-id: <<parameters.google-project-id>>
          image: <<parameters.image>>
          tag: << parameters.tag >>
          extra_build_args: <<parameters.docker-build-args>>
      - gcp-gcr/push-image:
          registry-url: <<parameters.registry-url>>
          google-project-id: <<parameters.google-project-id>>
          image: <<parameters.image>>
          tag: <<parameters.tag>>

What happened

So we use this rebranded job in all our repos but find consistently across them all that using the machine executor, it takes 50+ seconds to run the installation of gcloud. This is caused by the gcp-gcr/gcr-auth step which seems to invoke install from the gcp-cli orb.

I get the reason here is that I'm using a machine executor, but I can't seem to find any from circle that includes the gcloud-cli already. That would cut out 50+ seconds from our CI.

For reference below is an example where its actually quicker to build the docker image than it is to have gcloud installed.

I haven't tried remote docker as I would probably need to mount the workspace to the remote docker for the build to work, but would doing that and using a docker executor be one way of having gcloud cli pre-installed?

Expected behavior

Ideally I want to not install gcloud and save 50+ seconds of time.

But the only way I can see that happening is if there are some circleci machines or docker images with gcloud already installed. Is that the case with the default executor for this module?

I don't think I can use a docker executor as the build-image command would then need to point to a remote docker instance to work?

Is this unique to us, or do other people see this step taking a long time?

Orb needs storage.buckets.create

Orb version:

0.15.0

What happened:

Got following error:

denied: Token exchange failed for project '**************************'. Caller does not have permission 'storage.buckets.create'. To configure permissions, follow instructions at: https://cloud.google.com/container-registry/docs/access-control

Expected behavior:

Above error should not happen since the bucket already exists. It should just use the existing bucket.

Additional Information:

Using gcp-gcr orb with OIDC auth from gcp-cli orb?

Describe Request:

I am using this gcp-gcr orb to push container images to GCR.

I would like to use OpenID Connect tokens to authenticate to GCR.

This seems to be impossible with gcp-gcr's gcr-auth command as it always calls gcp-cli/setup without plumbing the OIDC-related options:

gcp-gcr-orb/src/commands/gcr-auth.yml

Lines 36 to 48 in ee205ad

	steps:
	- gcp-cli/setup:
	google_project_id: <<parameters.google-project-id>>
	google_compute_zone: <<parameters.google-compute-zone>>
	google_compute_region: <<parameters.google-compute-region>>
	gcloud_service_key: <<parameters.gcloud-service-key>>
	- run:
	name: gcloud auth configure-docker
	environment:
	ORB_ENV_PROJECT_ID: << parameters.google-project-id >>
	ORB_VAL_REGISTRY_URL: << parameters.registry-url >>
	command: << include(scripts/gcr-auth.sh) >>

Examples:

The gcp-cli command is pretty straightforward:

          - gcp-cli/setup:
              use_oidc: true

There's other parameters but they have defaults, so it's just the boolean flag that needs toggling at a bare minimum.

Supporting Documentation Links:

https://circleci.com/docs/openid-connect-tokens/

build_and_push_image not working with custom "gcloud-service-key" var

Orb version

0.0.5 (0.0.7 still affected according to orb code)

What happened

  build_and_push_image:
    jobs:
      - gcp-gcr/build_and_push_image:
          gcloud-service-key: GCLOUD_SERVICE_KEY_CUSTOM

this does not work as the gcp-cli/initialize step still uses the default env-var name

Store service account
echo $GCLOUD_SERVICE_KEY > ${HOME}/gcloud-service-key.json

Expected behavior

the env-var name from parameter is used.

parameter needs to be passed on here

gcp-gcr-orb/src/@orb.yml

Line 162 in fdfeca8

google-project-id: <<parameters.google-project-id>>

and here

gcp-gcr-orb/src/@orb.yml

Line 56 in fdfeca8

google-project-id: <<parameters.google-project-id>>

this is partially fixed in the stale PRs #5 and #3

Build and push multiple tags

Describe Request:

I was wondering if it was possible to build or push multiple tags using this orb. Currently it only looks like 1 string can be passed in

Examples:

- gcp-gcr/push-image:
          image: pluto-api
          registry-url: gcr.io
          tag: [$CIRCLE_SHA1, "latest", "v2.2.1"]

Supporting Documentation Links:

extra_build_args case inconsistencies

Orb version 0.7.1

The "extra build args" parameter name extra_build_args is snake case, while all other parameters are kebab case (in this orb and others). In particular cf.

aws-ecr/build-image:
  extra-build-args: <blah>

gcp-gcr/build-image:
  extra_build_args: <bleurgh>

If a PR would help please ping me.

user circleci can't push to GCR without sudo

Orb version

0.3.0

What happened

After successfully running gcr-auth command, I always get this error when I want to push image to GCR:

unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

Expected behavior

After successfully running gcr-auth command, I can push image to GCR with circleci user.

My Guess

When I SSH, I found /home/circleci/.docker folder empty, while /root/.docker had config.json.
I think this is because gcloud auth configure-docker was run with sudo.

# Set sudo to work whether logged in as root user or non-root user
if [[ $EUID == 0 ]]; then export SUDO=""; else export SUDO="sudo"; fi

# configure Docker to use gcloud as a credential helper
mkdir -p /home/circleci/.docker
$SUDO gcloud auth configure-docker --quiet --project $<<parameters.google-project-id>>

so giving the user circleci ownership to /home/circleci/.docker is useless, because after all the user still can't push the image, except with sudo of course.

# if applicable, provide circleci user access to the docker config file
if [[ -d /home/circleci/.docker ]]; then
$SUDO chown circleci:circleci /home/circleci/.docker -R
fi
if [[ -d /home/circleci/.config ]]; then
$SUDO chown circleci:circleci /home/circleci/.config -R
fi

Config files using the gcp-gcr orb are invalid

Orb version

0.7.1

What happened

Config files are no longer valid if they use the gcp-gcr: circleci/[email protected] orb. A large error is generated that seems to be related to the docker orb. This can be replicated locally by using circleci config validate.

Expected behavior

Using the gcp-gcr orb should not make config files invalid.

Add option to set version parameter of setup_remote_docker

Describe Request:

I would like to set the version parameter of setup_remote_docker to overcome an issue related to NodeJS. From looking at the orb's code there doesn't seem to be an option to do so.

Examples:

setup-remote-docker:
     version: 19.03.13

Supporting Documentation Links:

https://support.circleci.com/hc/en-us/articles/360050934711

Not working anymore under Ubuntu 22.04

Orb version:

0.15.0

What happened:

I tried to update the docker base image from cimg/base:2022.08 to cimg/base:2022.09.
This new version now uses Ubuntu 22.04 as the default version (latest LTS + 4 month) and my guess is that (like many other OS/distrib) this version of Ubuntu got rid of Python < 3.10.

Now running the orb (with gcp-gcr/gcr-auth) gives this error:

ERROR: gcloud failed to load: module 'collections' has no attribute 'MutableMapping'
gcloud_main = _import_gcloud_main()
import googlecloudsdk.gcloud_main
from googlecloudsdk.api_lib.iamcredentials import util as iamcred_util
from googlecloudsdk.api_lib.util import exceptions
from googlecloudsdk.core.resource import resource_printer
from googlecloudsdk.core.resource import config_printer
from googlecloudsdk.core.resource import resource_printer_base
from googlecloudsdk.core.resource import resource_projector
from google.protobuf import json_format as protobuf_encoding
from google.protobuf import symbol_database
from google.protobuf import message_factory
from google.protobuf import reflection
from google.protobuf.internal import python_message as message_impl
from google.protobuf.internal import containers
MutableMapping = collections.MutableMapping

This usually indicates corruption in your gcloud installation or problems with your Python interpreter.

Please verify that the following is the path to a working Python 2.7 or 3.5+ executable:
/usr/bin/python3

If it is not, please set the CLOUDSDK_PYTHON environment variable to point to a working Python 2.7 or 3.5+ executable.

If you are still experiencing problems, please reinstall the Cloud SDK using the instructions here:
https://cloud.google.com/sdk/

Exited with code exit status 1

Expected behavior:

It should work fine.

Additional Information:

/

Change image used because of depreciation

Orb version:

Any version

What happened:

Today (March 3rd) this orb is not working because of the ongoing brownout The image used by this orb is ubuntu-2004 and it is deprecated.

Expected behavior:

I would expect this orb to be working since it is maintained by CircleCI and you are aware on the depreciation and brownout.

Need a timeout parameter, just like in the AWS ECR Orb

Describe Request:

Sometimes, lengthy builds need more that 10 minutes with no output. Currently, The AWS ECR orb provides this option, while the GCR orb does not.

Examples of proposed solution:

gcp-gcr-orb-build-and-push-image-cmd:
steps:
- checkout
- gcp-gcr-orb/gcr-auth
- gcp-gcr-orb/build-image:
image: ${CIRCLE_PROJECT_REPONAME}
tag: ${FINAL_IMAGE_TAG}
extra_build_args: --build-arg APP_ENV=${APP_ENV}
no_output_timeout: 30m

Supporting Documentation Links:

Docs for AWS ECR Orb:

https://circleci.com/orbs/registry/orb/circleci/aws-ecr

docker push failing with 0.15.1 patch

Orb version:

0.15.1

What happened:

Our pipelines started failing with the release of gcp-gcr orb 0.15.1

We have been using gcp-gcr: circleci/[email protected] with no issues prior.

The error step output:

#!/bin/bash -eo pipefail
#!/bin/bash 

IFS="," read -ra DOCKER_TAGS <<< "$ORB_EVAL_TAG"
PROJECT_ID="${!ORB_ENV_PROJECT_ID}"

for tag_to_eval in "${DOCKER_TAGS[@]}"; do
    TAG=$(eval echo "$tag_to_eval")
    docker push "$ORB_VAL_REGISTRY_URL/$PROJECT_ID/$ORB_VAL_IMAGE:$TAG"
done

if [ -n "$ORB_VAL_DIGEST_PATH" ]; then
    mkdir -p "$(dirname "$ORB_VAL_DIGEST_PATH")"
    SAMPLE_FIRST=$(eval echo "${DOCKER_TAGS[0]}")
    docker image inspect --format="{{index .RepoDigests 0}}" "$ORB_VAL_REGISTRY_URL/$PROJECT_ID/$ORB_VAL_IMAGE:$SAMPLE_FIRST" > "$ORB_VAL_DIGEST_PATH"
fi

invalid reference format: repository name must be lowercase

Exited with code exit status 1
CircleCI received exit code 1

This appears to be the contents of the new push-image.sh file that appeared in 0.15.1.

Re-run with SSH showed that the ORB_VAL_* environment variables were not set, so they were not getting passed through. This explains the cryptic docker error at least.

Also notable is that we don't use the default machine executor, but prefer instead docker (cimg/base:2022.08) for performance and cost reasons. This should not make a difference, I would expect, but there could be some unexpected interaction beyond my perception.

Expected behavior:

Working as before.

Suggestion: This was a significant refactor, not a patch, should have been 0.16 really.

Additional Information:

Workaround is currently pinning to 0.15.0, but would rather not.

Example is not working

Orb version

What happened

When using the example from this orb (and https://circleci.com/orbs/registry/orb/circleci/gcp-gcr) , you get

Cannot find a definition for job named gcp-gcr/build_and_push_image_using_remote_docker

This is because the job is actually named build_and_push_image as seen here https://github.com/CircleCI-Public/gcp-gcr-orb/blob/master/src/%40orb.yml#L126

Expected behavior

Example being correct and working

Old version of gcloud

The CircleCI builds are using an old version of gcloud. This needs to be fixed.

Not working with standard Artifact Registry repositories

Orb version: 0.16.2

version: 2.1

orbs:
  gke: circleci/[email protected]
  helm: circleci/[email protected]
  gcp-gcr: circleci/[email protected]

jobs:
  build_and_push:
    executor: gcp-gcr/default
    steps:
      - checkout
      - run: cp -a ~/project/docker/${CIRCLE_BRANCH}/config.json ~/project/config.json
      - gcp-gcr/gcr-auth:
          registry-url: us-east4-docker.pkg.dev
      - gcp-gcr/build-image:
          image: my-custom-service
          tag: ${CIRCLE_BRANCH}-${CIRCLE_SHA1}
          no_output_timeout: 10m
          registry-url: us-east4-docker.pkg.dev
          dockerfile: Dockerfile.${CIRCLE_BRANCH}
      - gcp-gcr/push-image:
          image: my-custom-service
          registry-url: us-east4-docker.pkg.dev
          tag: ${CIRCLE_BRANCH}-${CIRCLE_SHA1}

What happened:

Error occurred during push:

+ docker push us-east4-docker.pkg.dev/*******************/my-custom-service:dev-bbe295b623056bfd0ac73a13a2a10e84a6638775
The push refers to repository [us-east4-docker.pkg.dev/*******************/my-custom-service]
24c1323c3697: Retrying in 1 second 
92ea868f867f: Retrying in 1 second 
6aaf570d7fc8: Retrying in 1 second 
cb19e85a901d: Retrying in 1 second 
a8b4b33f7690: Retrying in 1 second 
7cd8738126ff: Waiting 
cb591dd771d8: Waiting 
488ed91819d9: Waiting 
7e98a34e8d5d: Waiting 
59c677849659: Waiting 
b485c6cd33a6: Waiting 
6aa872026017: Waiting 
43ba18a5eaf8: Waiting 
ff61a9b258e5: Waiting 
name invalid: Missing image name. Pushes should be of the form docker push HOST-NAME/PROJECT-ID/REPOSITORY/IMAGE

Expected behavior:

It should push to Artifact Registry repo

Additional Information:

It's like we need a field to indicate if the build is for legacy Container Registry or standard Artifact Registry repository. Something like:

      - gcp-gcr/push-image:
          image: my-custom-service
          repository-url: my-project-repo
          registry-url: us-east4-docker.pkg.dev
          tag: ${CIRCLE_BRANCH}-${CIRCLE_SHA1}

if repository-url is empty, it is a GCR push; otherwise, it is a push to Artifact Registry repo:

docker push us-east4-docker.pkg.dev/PROJECT_ID/{repository-url}/{image}

[FEATURE] Add arguments to build_image command

Orb version

0.5.1
Also not present in latest: 0.6.0

What happened

Using the build-image command your currently cannot pass any arguments to the docker build command.

This is important for passing metadata into the container image such as the git commit SHA. There's probably a huge list of meta people might want to add.

Expected behavior

It would be really useful to expose an argument list, or map and have those passed to the docker build command. The solution would allow people to specify the key values they want to embed within the image.

It might be something like:

# command
      - gcp-gcr/build-image:
          registry-url: <<parameters.registry-url>>
          google-project-id: <<parameters.google-project-id>>
          image: <<parameters.image>>
          tag: << parameters.tag >>
          path-to-dockerfile: <<parameters.path-to-dockerfile>>
          arguments: <<parameters.build-arguments>>

# Using the job
      - build_and_push_image:
          image: $CIRCLE_PROJECT_REPONAME
          tag: $CIRCLE_SHA1
          build-arguments: 
            - GITHASH: $CIRCLE_SHA1
            - A_KEY: "arandomvalue"
          registry-url: gcr.io
          context: gcr-docker-images
          requires:
            - build
          filters:
            branches:
              only:
                - staging
                - prod

Why use gcloud alpha?

Orb version

0.0.7

What happened

I just want to ask, why you use alpha version gcloud alpha auth configure-docker instead of just auth configure-docker?

BTW, thanks for making this orb

path parameters description of build-and-push-image command needs more information

Orb version

0.6.1

What happened

When trying to follow the documentation for the command build-and-push-image, I'm not able to understand how is the path supposed to be configured. I have 2 images that I'm trying to build and push from 2 Dockerfiles :

and my config looking like this :

version: 2.1
orbs:
  gcp-gcr: circleci/[email protected]
workflows:
  version: 2
  build:
    jobs:
      - gcp-gcr/build-and-push-image:
          image: eu.gcr.io/${PROJECT_ID}/frontend
          tag: $CIRCLE_BRANCH
          path: ~/frontend/
      - gcp-gcr/build-and-push-image:
          image: eu.gcr.io/${PROJECT_ID}/backend
          tag: $CIRCLE_BRANCH
          path: ~/project/backend/

I tried setting the path to multiple values like ./backend, ../backend, same issue with frontend path

Expected behavior

Could the documentation be more specific to which kind of path is expected ?

gcloud installation failure

Orb version

2.1

What happened

I encountered a gcloud installation failure:

Err:9 http://packages.cloud.google.com/apt cloud-sdk-/main amd64 Packages
  404  Not Found

Reading package lists... Done

W: The repository 'http://packages.cloud.google.com/apt cloud-sdk- Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Failed to fetch http://packages.cloud.google.com/apt/dists/cloud-sdk-/main/binary-amd64/Packages  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.
Exited with code 100

My config:

version: 2.1                                                                                                             
orbs:                                                                                                                                                                                                        
  gcp-gcr: circleci/[email protected]                                                                                        
jobs:                                                                                                                    
  mvn-push:                                                                                                              
    docker:                                                                                                              
      - image: circleci/openjdk:11.0.2                                                                                   
    steps:                                                                                                               
      - gcp-gcr/gcr-auth                                                                                                 
workflows:                                                                                                               
  build-and-push:                                                                                                        
    jobs:                                                                                                                
      - mvn-push:                                                                                                        
          context: my-context

As a reference, circleci/[email protected] is working fine.

Expected behavior

gcloud should install successfully.

The version installed (458.0.1) differs from the version requested (459.0.0). Uninstalling v458.0.1

Orb version:

orbs:
gcp-gcr: circleci/[email protected]
cloudrun: circleci/[email protected]

What happened:

Error

The version installed (458.0.1) differs from the version requested (459.0.0).
Uninstalling v458.0.1...
sudo is required to uninstall the Google Cloud SDK.
Please install it and try again.
Failed to uninstall the current version.

Exited with code exit status 1

Expected behavior:

No error

Support artifact registry Docker repository.

Describe Request:

GCP recently released Artifact Registry that supports docker registry as well

https://cloud.google.com/artifact-registry/docs/docker/authentication#gcloud-helper

This orb almost supports publishing docker image to the Artifact repository but there are a couple of changes that need to happen for this to work.

Examples:

executors:
  custom-docker-executor:
    machine:
      image: ubuntu-2004:202010-01    # recommended linux image - includes Ubuntu 16.04, docker 18.09.3, docker-compose 1.23.1
      docker_layer_caching: true

# many lines in between
- gcp-gcr/build-and-push-image:
          executor: custom-docker-executor
          pre-steps:
            - checkout
            - run: ls -al
          context: ganus-example-stack-v2
          path: ./dataflow/
          workspace-root: ./dataflow/
          docker-context: ./dataflow/
          image: ganus-example-stack-v2/ganus-example-stack-v2-image

There two problems that make this fail:

1. the gcloud in the default executor is almost 200 version behind current version and thus does not allow specifying specific repositories when establishing docker credentials. That problem was solved by using the later ubuntu machine defined as custom-docker-executor
2. the establishing docker credentials command has to have the registry passed-in for docker to recognize that push is authenticated

gcp-gcr-orb/src/commands/gcr-auth.yml

Line 46 in b42aa3c

gcloud auth configure-docker --quiet --project $<<parameters.google-project-id>>

needs to be changed to something like this:

gcloud auth configure-docker  $<<parameters.regisrty-url>> --quiet --project $<<parameters.google-project-id>>

Supporting Documentation Links:

https://cloud.google.com/artifact-registry/docs/docker/authentication#gcloud-helper

`extra_build_args` parameter causes docker build error

Orb version:

0.13.0

What happened:

when suppling extra_build_args it causes a docker build error: "docker build" requires exactly 1 argument."

Expected behavior:

It should build the docker image successfully

Additional Information:

circleci config.yaml file:

# Define steps for individual jobs defined above
jobs:
  dbt_gcr_image:
    executor: python
    parameters:
      environment:
        description: Deployment environment
        type: string
    steps:
      - checkout
      - gcp-gcr/gcr-auth
      - setup_remote_docker:
          docker_layer_caching: true
      - gcp-gcr/build-image:
          image: dbt-bq-elt
          registry-url: eu.gcr.io
          extra_build_args: "--build-arg GCLOUD_SERVICE_KEY=$GCLOUD_SERVICE_KEY --build-arg GOOGLE_PROJECT_ID=$GOOGLE_PROJECT_ID \
            --build-arg GOOGLE_COMPUTE_ZONE=$GOOGLE_COMPUTE_ZONE \
            --build-arg CIRCLE_BRANCH=$CIRCLE_BRANCH \
            --build-arg CIRCLE_USERNAME=$CIRCLE_USERNAME"
      - gcp-gcr/push-image:
          image: dbt-bq-elt
          registry-url: eu.gcr.io

generated docker build command: (i do not see anything wrong with it)

docker build --build-arg GCLOUD_SERVICE_KEY=$GCLOUD_SERVICE_KEY --build-arg GOOGLE_PROJECT_ID=$GOOGLE_PROJECT_ID --build-arg GOOGLE_COMPUTE_ZONE=$GOOGLE_COMPUTE_ZONE --build-arg CIRCLE_BRANCH=$CIRCLE_BRANCH --build-arg CIRCLE_USERNAME=$CIRCLE_USERNAME \
  -f ./Dockerfile \
  $docker_tag_args \
  .

tag-image command doesn't expand envvars

Orb version:

0.15

What happened:

steps: - gcp-gcr/tag-image: image: $CIRCLE_JOB source-tag: $CIRCLE_BRANCH target-tag: latest

Resulted in ERROR: (gcloud.container.images.add-tag) [gcr.io/**********/$CIRCLE_JOB:master] digest must be of the form "sha256:<digest>"

Expected behavior:

It should have expanded the image in the same way that source-tag was, but it did not

Additional Information:

Probably the same fix that was done in #71 for build-and-push needs to be applied to add-tag as well

Multiple tags support

Orb version

0.0.4

What happened

If I inform in the tag parameter more than one value separated with commas.

Expected behavior

The pushed image should be tagged with all those tags informed in the tag parameter

Option to use buildkit

Describe Request:

It would be nice to be able to pass option
use-buildkit: true
to docker/build step

Examples:

Supporting Documentation Links:

Facing issue while pushing image to GCP artifact registry

Orb version:

---

version: 2.1

orbs:
gcp-gcr: circleci/[email protected]

What happened:

we are migrating from GCR to GCP artifact registry so modified the orb repo to use google artifact registry url
but its able to build the image but not able to push the image to artifact registry. its working fine with GCR

Expected behavior:

It should push the image to artifact registry

Additional Information:

here is ORB repo code we are using for artifact registry

`steps:

• checkout
• run:
  name: Authenticate gcloud CLI
  command: |
  echo $GCP_SERVICE_KEY | gcloud auth activate-service-account --key-file=-
  gcloud auth list
  gcloud --quiet config set project ${<<parameters.gcp-project-id>>}
  # check to see if cluster parameters are defined
  if [ ! -z ${<<parameters.gke-cluster-name>>} ]; then
  if [ $(gcloud container clusters list --format=json | jq ".[] |
  select(.name == "$<<parameters.gke-cluster-name>>") | .locations | length") -gt 1 ];
  then
  gcloud --quiet config set
  compute/region ${<<parameters.gke-cluster-compute-region>>}
  else
  gcloud --quiet config set
  compute/zone ${<<parameters.gke-cluster-compute-zone>>}
  fi
  fi
  gcloud auth configure-docker europe-docker.pkg.dev
• setup_remote_docker
• run:
  name: Set build variables from build.json
  command: |
  SERVICE_NAME=$(jq -r '.name' build.json)
  VERSION=$(jq -r '.version' build.json)
  DOCKER_TAG=$VERSION
  if [ "${<< parameters.docker-image-suffix >>}" != "" ]; then
  DOCKER_TAG=$DOCKER_TAG-${<< parameters.docker-image-suffix >>} >> $BASH_ENV
  fi
  if [ "$CIRCLE_BRANCH" = "develop" ] && [[ ! $VERSION == *"-develop" ]]; then
  DOCKER_TAG=$DOCKER_TAG-develop >> $BASH_ENV
  fi
  echo "Service name is $SERVICE_NAME, node package version is"
  "$VERSION and docker tag will be $DOCKER_TAG"
  TAG_COUNT=$(gcloud container images list-tags
  ${<<parameters.gcp-container-registry-url>>}/${SERVICE_NAME}
  --filter="tags=${DOCKER_TAG}" --format=json --quiet | jq ". | length")
  echo GCR image tag Count is $TAG_COUNT
  if [ $TAG_COUNT != 0 ]; then
  echo "ERROR: image tag exists. Found total of $TAG_COUNT image "
  "tags at: $<<parameters.gcp-container-registry-url>>"
  "/$SERVICE_NAME:$DOCKER_TAG"
  exit 1
  fi
  # Debug: Print Docker Tag and Image URL
  echo "Docker Tag: $DOCKER_TAG"
  echo "Image URL: $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:$DOCKER_TAG"
  gcloud auth list
  # tag with generated unique tag and update latest
  docker build --build-arg NPM_TOKEN=${<<parameters.npm-token-var>>} -t
  $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:$DOCKER_TAG
  -t $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:latest
  <<parameters.path-to-dockerfile>>
  docker images
  # push all tags
  echo "Pushing Docker image: $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:$DOCKER_TAG"
  docker push
  $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:$DOCKER_TAG
  echo "Pushing latest Docker image: $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:latest"
  docker push
  $<<parameters.gcp-container-registry-url>>/$SERVICE_NAME/$SERVICE_NAME:latest`

error we are getting

`Service name is lender-deployment, node package version is 1.1.23 and docker tag will be 1.1.23
GCR image tag Count is 0
Docker Tag: 1.1.23
Image URL: *******************************/lender-deployment/lender-deployment:1.1.23
Credentialed Accounts
ACTIVE ACCOUNT

•   circleci@************************.iam.gserviceaccount.com
  

To set the active account, run:
$ gcloud config set account ACCOUNT

[+] Building 28.6s (14/14) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.03kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for europe-docker.pkg.dev/koodoo-infra-share 2.9s
=> [auth] /python/python:pull token for europe-d 0.0s
=> [build 1/3] FROM europe-docker.pkg.dev//pytho 3.9s
=> => resolve europe-docker.pkg.dev/************************/python/pyth 0.0s
=> => sha256:b380bbd43752f83945df8b5d1074fef8dd044820e 27.14MB / 27.14MB 1.9s
=> => sha256:14063a2781d6ddd50c6afb4a9e22cccf2205cb04a72 2.77MB / 2.77MB 1.4s
=> => sha256:5a63271f8164c4a1fd42b70f29316cfe5ec83c34c 10.99MB / 10.99MB 1.5s
=> => sha256:3757de4f921083546ee8bd0a33d84c9784a6eafc7fc 1.78kB / 1.78kB 0.0s
=> => sha256:fffe3935e6ccd74861da2903369daf76f80b4ef7cad 9.11kB / 9.11kB 0.0s
=> => sha256:8bcf4fd3160ad38c522f2edcf11277e643a6ebc542bdbe7 233B / 233B 1.6s
=> => sha256:31aed500758ca862f26aba69e07486cab51a610c5e0 2.64MB / 2.64MB 2.6s
=> => sha256:3846e6476bca479e8a20450bf99c14249c4a8ef15570516 817B / 817B 2.2s
=> => extracting sha256:b380bbd43752f83945df8b5d1074fef8dd044820e7d3aef3 1.0s
=> => sha256:e5c71c2c4dae9f2458289f2d1f7a7074aba801418c7dcb3 513B / 513B 2.5s
=> => extracting sha256:14063a2781d6ddd50c6afb4a9e22cccf2205cb04a72caff0 0.1s
=> => extracting sha256:5a63271f8164c4a1fd42b70f29316cfe5ec83c34cb6de728 0.4s
=> => extracting sha256:8bcf4fd3160ad38c522f2edcf11277e643a6ebc542bdbe70 0.0s
=> => extracting sha256:31aed500758ca862f26aba69e07486cab51a610c5e03928d 0.2s
=> => extracting sha256:3846e6476bca479e8a20450bf99c14249c4a8ef155705161 0.0s
=> => extracting sha256:e5c71c2c4dae9f2458289f2d1f7a7074aba801418c7dcb38 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 9.52kB 0.0s
=> [stage-1 2/6] WORKDIR /app 0.2s
=> [build 2/3] COPY requirements.txt . 0.2s
=> [stage-1 3/6] RUN addgroup --system user && adduser --system --no-cre 0.5s
=> [build 3/3] RUN pip install --user -r requirements.txt --no-warn-scr 18.2s
=> [stage-1 4/6] COPY ./src /app 0.0s
=> [stage-1 5/6] COPY ./config/config.json /app/config/config.json 0.0s
=> [stage-1 6/6] COPY --from=build --chown=user:user /root/.local /root/ 0.9s
=> exporting to image 1.5s
=> => exporting layers 1.5s
=> => writing image sha256:156220e0b5865bf506ef31f95753d718d9cdf85a594bd 0.0s
=> => naming to *******************************/lender-deployment/lender 0.0s
=> => naming to *******************************/lender-deployment/lender 0.0s
REPOSITORY TAG IMAGE ID CREATED SIZE
*******************************/lender-deployment/lender-deployment 1.1.23 156220e0b586 2 seconds ago 378MB
*******************************/lender-deployment/lender-deployment latest 156220e0b586 2 seconds ago 378MB

Pushing Docker image: /lender-deployment/lender-deployment:1.1.23
The push refers to repository [/lender-deployment/lender-deployment]
1afd1bc92435: Preparing
31cf4414da23: Preparing
c96bb6c6a8c3: Preparing
a8dc6f868f8a: Preparing
bbce02a022f3: Preparing
9d19eb5c7836: Waiting
e262df620e78: Waiting
a1771f126974: Waiting
19a51c156a1b: Waiting
401d40a3e0d6: Waiting
3ce18771576c: Waiting
e81bff2725db: Waiting
unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

Exited with code exit status 1`

same workflow earlier working for GCR so there is no permission issue.
Let me know if any other orb version need to update to fix the issue or any other modification in yaml file

The version installed (451.0.0) differs from the version requested (451.0.1)

Unable to use interpolated var for pipeline values for "image:" in build-and-push-image job

Orb version:

0.15

What happened:

version: 2.1

orbs:
  gcp-gcr: circleci/[email protected]

workflows:
  build_and_push_image:
    jobs:
      - gcp-gcr/build-and-push-image:
          image: ${CIRCLE_PROJECT_REPONAME}
          registry-url: us.gcr.io
          tag: ${CIRCLE_SHA1:0:7},latest

image: ${CIRCLE_PROJECT_REPONAME} should read as the pipeline value CIRCLE_PROJECT_REPONAME. It cannot be interpolated and returns error in pipeline "invalid reference format: repository name must be lowercase"

Expected behavior:

Error should not exist. Variable should be interpolated. Image repository should be created using the value for CIRCLE_PROJECT_REPONAME.

Additional Information:

Update gcp-gcr-ord/src/scripts/push-image.sh
Add ORB_VAL_IMAGE=$(eval echo "$ORB_VAL_IMAGE") on line 5 of push-image.sh

Tested and confirms that adding this works, the var is read properly, and the pipeline passes without failure

How do I tag the branch name slug in gcp-gcr/tag-image?

Orb version

0.7.1

What happened

In operations such as gitflow, branch names such as fetature/xxx are given, but you can't set tags with slush in docker's tags, and gitlab-ci and others provide slug names as environment variables.

Perhaps the scripting feature of GCP-GCR can be used to convert and tag the BRANCH name. But it's not ideal.

Being able to set a script to target-tag is a necessary feature in my opinion.
I'm not familiar with cricleci, so I'm not immediately sure it's possible.

      - gcp-gcr/add-image-tag:
          name: tagging_branch_name
          requires:
          image: builtImage
          registry-url: gcr.io
          source-tag: latest
          target-tag: echo $CIRCLE_BRANCH | sed -e "s/[^a-zA-Z]/\-/g"

ERROR: (gcloud.container.images.add-tag) Invalid tag: echo test/branch/name | sed -e s/[^a-zA-Z]/-/g

Expected behavior

Google Cloud SDK is Unavailable

Orb version: 0.15.0

What happened:

An outage at https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/ has caused the Cloud SDK to not be available, thereby breaking any jobs that need to install it in order to use the GCP CLI.

https://app.circleci.com/pipelines/github/swift-school/swift/3174/workflows/1b6adbfb-c89a-42c3-99f1-6821bc1618d1/jobs/14961

Expected behavior:

The Google Cloud SDK should be cached locally to Circle and the cached copy should be referenced by this orb so that outages at Google don't affect CircleCI services. This might be a good time to update the client revision, too -- 293 is significantly older than 383.

Additional Information: