circleci-public / gcp-cli-orb Goto Github PK

View Code? Open in Web Editor NEW

9.0 14.0 33.0 85 KB

Install and configure the Google Cloud CLI (gcloud)

Home Page: https://circleci.com/orbs/registry/orb/circleci/gcp-cli

License: MIT License

Shell 100.00%

circleci-orbs google google-cloud gcloud gcloud-sdk

gcp-cli-orb's Introduction

GCP CLI Orb

Easily install and configure the Google Cloud CLI in your CircleCI jobs.

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.

gcp-cli-orb's People

Contributors

Stargazers

Watchers

gcp-cli-orb's Issues

Cannot use gcloud config initialized by the "initialize" orb command because config is root

All the commands executed by the initialize orb command are run either by root or with sudo, hence, the gcloud auth commands (executed by the initialize orb command) generate a valid gcloud config for the root user, not for the user running in a container when a job relies on a docker container executor and not a "machine" executor.

Question : why did you choose to use sudo when user is not root? (that is the cas when the job is running inside a container)

Note : this issue is a follow up of this Twitter thread : https://twitter.com/drazisil/status/1097909301857927168?s=17

3.3.1 initialize gone?

Orb version

3.1.1
Braking changes when moving from v2.4.1

The initialise syntax appears to have been replaced with setup?
and then it throws this error.

WARNING: You do not appear to have access to project [********************] or it does not exist.
ERROR: (gcloud.config.set) The project property must be set to a valid project ID, not the project name [********************]

I know both the env vars are fine, since they work perfectly in 2.4.1 - and I can confirm it is the project ID.

before - works 2.4.1

      - gcp-cli/initialize:
          gcloud-service-key: GCLOUD_CUSTOM
          google-compute-region: AUSTRALIA_REGION
          google-project-id: GOOGLE_PROJECT_ID

after - failing 3.1.1

      - gcp-cli/setup:
          google_project_id: GOOGLE_PROJECT_ID
          gcloud_service_key: GCLOUD_CUSTOM
          google_compute_region: AUSTRALIA_REGION

curl: (16) Error in the HTTP2 framing layer

Orb version

2.1.0

What happened

 gcp-cli/install:
          version: 320.0.0

often fails with the following error:

#!/bin/bash -eo pipefail
install () {
  # 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
  cd ~/
  curl -Ss --retry 5 https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-320.0.0-linux-x86_64.tar.gz | tar xz
  echo 'source ~/google-cloud-sdk/path.bash.inc' >> $BASH_ENV
}

if grep 'docker\|lxc' /proc/1/cgroup > /dev/null 2>&1; then
  if [[ $(command -v gcloud) == "" ]]; then
    install
  else
    echo "gcloud CLI is already installed."
  fi
else
  echo "----------------------------------------------------------------------------------------------------"
  echo "this is a machine executor job, replacing default installation of gcloud CLI"
  echo "----------------------------------------------------------------------------------------------------"
  sudo rm -rf /opt/google-cloud-sdk
  install
fi
curl: (16) Error in the HTTP2 framing layer

Exited with code exit status 16
CircleCI received exit code 16

Expected behavior

GCP cli would download and install properly

Notes

After reaching out to support, this is what was suggested:

Hi Lois,

Thank you for writing to CircleCI Support!

The curl: (16) Error in the HTTP2 framing layer is occurring on the dl.google.com server's end, and is likely due to a change or an error in their infrastructure. Let's try to seem if forcing cURL to use HTTP 1.1 resolves your issue. We can replace the command with it's source to allow us to add the --http1.1 and -v (verbose) option:

#!/bin/bash -eo pipefail
install () {
  # 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
  cd ~/
  curl -Ssv --retry 5 --http1.1 https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-320.0.0-linux-x86_64.tar.gz | tar xz
  echo 'source ~/google-cloud-sdk/path.bash.inc' >> $BASH_ENV
}

if grep 'docker\|lxc' /proc/1/cgroup > /dev/null 2>&1; then
  if [[ $(command -v gcloud) == "" ]]; then
    install
  else
    echo "gcloud CLI is already installed."
  fi
else
  echo "----------------------------------------------------------------------------------------------------"
  echo "this is a machine executor job, replacing default installation of gcloud CLI"
  echo "----------------------------------------------------------------------------------------------------"
  sudo rm -rf /opt/google-cloud-sdk
  install
fi
Please let me know if you see any failures via HTTP 1.1, and we will see about putting that option in the source of the orb.

Best,

I will be attempting this on my end a couple times and report back.

`gcp-cli/setup` command won't pass with gcloud latest version (429.0.0)

Orb version

3.0.1

What happened

Installing the latest gcloud version (429.0.0) will break on the gcp-cli/setup command while running the step
Initialize gcloud CLI to connect to Google Cloud with the error

ERROR: gcloud crashed (AttributeError): 'bool' object has no attribute 'lower'

Knowing that we can set the version, however this is part of the gcp-gke/publish-and-rollout-image job on the gcp-gke orb.

Expected behavior

The setup should pass successfully regardless the version.

failed to gcloud version

Orb version

2.4.1

What happened

gcloud version failed

ERROR: gcloud failed to load: module 'collections' has no attribute 'Mapping'
    gcloud_main = _import_gcloud_main()
    import googlecloudsdk.gcloud_main
    from googlecloudsdk.calliope import cli
    from googlecloudsdk.calliope import actions
    from googlecloudsdk.calliope import markdown
    from googlecloudsdk.calliope import usage_text
    from googlecloudsdk.calliope import parser_arguments
    from googlecloudsdk.calliope import parser_completer
    from googlecloudsdk.core.console import progress_tracker
    class _BaseStagedProgressTracker(collections.Mapping):

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

Gcloud installation not recognized in GKE runners

Orb version

2.4.1

What happened

In the step to install the latest gcloud version, we are seeing this when running on-prem CircleCI runners in our GKE cluster:

if grep 'docker\|lxc' /proc/1/cgroup > /dev/null 2>&1; then
  if [[ $(command -v gcloud) == "" ]]; then
    install
  else
    echo "gcloud CLI is already installed."
  fi
else
  echo "----------------------------------------------------------------------------------------------------"
  echo "this is a machine executor job, replacing default installation of gcloud CLI"
  echo "----------------------------------------------------------------------------------------------------"
  sudo rm -rf /opt/google-cloud-sdk
  install
fi

----------------------------------------------------------------------------------------------------
this is a machine executor job, replacing default installation of gcloud CLI
----------------------------------------------------------------------------------------------------
CircleCI received exit code 0

Expected behavior

We are using an image that has gcloud installed, so we expect it to skip this step. But the code is grepping for docker or lxc (grep 'docker\|lxc' /proc/1/cgroup). In order to work with our GKE runners, we'd need to include containerd (grep 'docker\|lxc\|containerd' /proc/1/cgroup).

GCP CLI Orb 1.5.0 failure

Orb version

1.5.0

What happened

Cannot install lsb-release so CLOUD_SDK_REPO = "cloud-sdk-" so gcp cli install fails

When the orb run "$SUDO apt-get update && $SUDO apt-get -y install lsb-release"
Here is the error: "E: Could not open file /var/lib/apt/lists/deb.debian.org_debian_dists_stretch-backports_main_binary-amd64_Packages.diff_Index - open (2: No such file or directory)"

You should fix apt to be able to install lsb-release properly

Here are the logs:

#!/bin/bash -eo pipefail
install () {
  # 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

  # Create an environment variable for the correct distribution
  if [[ $(command -v lsb_release) == "" ]]; then
    $SUDO apt-get update && $SUDO apt-get -y install lsb-release
    export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"
  else
    export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"
  fi

  # Add the Google Cloud SDK distribution URI as a package source
  echo "deb http://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | $SUDO tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

  # Import the Google Cloud public key
  if [[ $(command -v curl) == "" ]]; then
    $SUDO apt-get update && $SUDO apt-get -y install curl
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | $SUDO apt-key add -
  else
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | $SUDO apt-key add -
  fi

  # Update and install the Cloud SDK
  $SUDO apt-get update && $SUDO apt-get -y install google-cloud-sdk
}

if grep 'docker\|lxc' /proc/1/cgroup > /dev/null 2>&1; then
  if [[ $(command -v gcloud) == "" ]]; then
    install
  else
    echo "gcloud CLI is already installed."
  fi
else
  echo "----------------------------------------------------------------------------------------------------"
  echo "this is a machine executor job, replacing default installation of gcloud CLI"
  echo "----------------------------------------------------------------------------------------------------"
  sudo rm -rf /opt/google-cloud-sdk
  install
fi

echo "Success! gcloud has been installed; displaying version information:"
gcloud version
Get:1 http://security.debian.org/debian-security stretch/updates InRelease [94.3 kB]

Ign:2 http://deb.debian.org/debian stretch InRelease

Get:3 http://deb.debian.org/debian stretch-updates InRelease [91.0 kB]

Get:4 http://deb.debian.org/debian stretch-backports InRelease [91.8 kB]

Get:5 http://deb.debian.org/debian stretch Release [118 kB]

Get:6 http://deb.debian.org/debian stretch Release.gpg [2434 B]

Get:7 http://deb.debian.org/debian stretch-updates/main amd64 Packages.diff/Index [10.1 kB]

Get:8 http://deb.debian.org/debian stretch-updates/main amd64 Packages [27.2 kB]

Get:9 http://deb.debian.org/debian stretch-backports/main amd64 Packages.diff/Index [27.8 kB]

Get:9 http://deb.debian.org/debian stretch-backports/main amd64 Packages.diff/Index [27.8 kB]

Get:10 http://deb.debian.org/debian stretch-backports/main amd64 Packages [601 kB]

Get:11 http://security.debian.org/debian-security stretch/updates/main amd64 Packages [499 kB]

Get:12 http://deb.debian.org/debian stretch/main amd64 Packages [7082 kB]

Reading package lists... Done

E: Could not open file /var/lib/apt/lists/deb.debian.org_debian_dists_stretch-backports_main_binary-amd64_Packages.diff_Index - open (2: No such file or directory)
environment: line 7: lsb_release: command not found
deb http://packages.cloud.google.com/apt cloud-sdk- main
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

100  1326  100  1326    0     0  24888      0 --:--:-- --:--:-- --:--:-- 25018
OK

Ign:1 http://deb.debian.org/debian stretch InRelease

Hit:2 http://deb.debian.org/debian stretch-updates InRelease

Hit:3 http://deb.debian.org/debian stretch-backports InRelease

Hit:4 http://deb.debian.org/debian stretch Release

Ign:5 http://packages.cloud.google.com/apt cloud-sdk- InRelease

Ign:6 http://packages.cloud.google.com/apt cloud-sdk- Release

Ign:7 http://packages.cloud.google.com/apt cloud-sdk-/main all Packages

Ign:8 http://packages.cloud.google.com/apt cloud-sdk-/main amd64 Packages

Ign:7 http://packages.cloud.google.com/apt cloud-sdk-/main all Packages

Ign:8 http://packages.cloud.google.com/apt cloud-sdk-/main amd64 Packages

Ign:7 http://packages.cloud.google.com/apt cloud-sdk-/main all Packages

Ign:8 http://packages.cloud.google.com/apt cloud-sdk-/main amd64 Packages

Hit:9 http://security.debian.org/debian-security stretch/updates InRelease

Ign:7 http://packages.cloud.google.com/apt cloud-sdk-/main all Packages

Ign:8 http://packages.cloud.google.com/apt cloud-sdk-/main amd64 Packages

Ign:7 http://packages.cloud.google.com/apt cloud-sdk-/main all Packages

Ign:8 http://packages.cloud.google.com/apt cloud-sdk-/main amd64 Packages

Ign:7 http://packages.cloud.google.com/apt cloud-sdk-/main all Packages

Err:8 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

Expected behavior

should work as usual ;)

Orb installing an old version of gcloud; install is not OS or distro agnostic

Orb version

any

What happened

gcloud is installed via apt-get, & the version installable via apt-get is from 2018

this means certain gcloud commands used by other GCP orbs aren't available

Expected behavior

the latest stable version of gcloud should be installed (and, optionally, we should provide a way for users to specify a particular version of gcloud to instal)

`pyenv-version-name: command not found` when running "GCloud version" on `machine: true`

Orb version

1.8.4

What happened

Running with machine: true

Job "GCloud version" failed with this output:

#!/bin/bash -eo pipefail
gcloud version
/opt/circleci/.pyenv/libexec/pyenv-exec: line 24: pyenv-version-name: command not found
/opt/circleci/.pyenv/libexec/pyenv-exec: line 24: pyenv-version-name: command not found
/opt/circleci/.pyenv/libexec/pyenv-exec: line 24: pyenv-version-name: command not found
/opt/circleci/.pyenv/libexec/pyenv-exec: line 24: pyenv-version-name: command not found
/opt/circleci/.pyenv/libexec/pyenv-exec: line 24: pyenv-version-name: command not found

Exited with code exit status 127
CircleCI received exit code 127

Workflow URL: https://app.circleci.com/jobs/github/Jupiter-Inc/jupiter-platform/3768

Expected behavior

The gcp cli is installed successfully, without failure.

Fails to install components if gcloud came from apt

Orb version

3.0.1

What happened

We embed steps from this orb in an orb of our own, and so sometimes we end up calling it in a workflow that is running from an image that has at least the base gcloud already installed, such as gcr.io/google.com/cloudsdktool/cloud-sdk, since our orb steps that need gcloud sometimes run in containers without gcloud pre-installed, and sometimes in ones that have it installed.

This orb detects that gcloud is already installed, but then when trying to install the requested components, it always uses gcloud components install ..., which is not allowed when gcloud was installed via apt (or some other package manager). This causes the install step to fail with an error like this:

ERROR: (gcloud.components.install) 
You cannot perform this action because the Google Cloud CLI component manager 
is disabled for this installation. You can run the following command 
to achieve the same result for this installation: 

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

Expected behavior

It should install the requested components via apt-get when necessary.

Additional Notes

Google is in the process of trying to transition the name of the "sdk" package to "cli", and the names of the component packages needs to match the main gcloud package, so e.g. if google-cloud-cli is installed, component packages need to be installed as google-cloud-cli-<component>, trying to install google-cloud-sdk-<component> will fail, and vice versa. It doesn't help matters that the error message from gcloud components install always tells you to use the sdk variant even when that's wrong.

Bug: Gcloud fails on machine with Python 3.10

Orb version 2.4.1

What happened

A python feature has been deprecated and removed in 3.10, which causes gcloud to fail.

Expected behavior

Choose a version prior to 3.10 depending on the conditions of the image.

Feature request: Use OIDC and Workload Identity Federation for increased security

CircleCI recently began supporting OIDC, similarly to GitHub Actions and other CI providers (https://circleci.com/docs/2.0/openid-connect-tokens/). The current GCP orbs use service account keys, whereas the GCP GitHub Actions use OIDC as best practices indicate. I'm not comfortable recommending these orbs to the rest of my team until they use OIDC instead of requiring service account private key management. Thank you!

Failed to install gcloud on latest ubuntu machine executor

Orb version

circleci/[email protected]

machine image: ubuntu-2204:2024.03.1(from ubuntu-2204:edge) and ubuntu-2004:2024.03.1(from: ubuntu-2004:edge)

What happened

Installation failed.

error message:

The version installed (470.0.0) matches the version requested (470.0.0).
Skipping installation.

ERROR: (gcloud.components.install) You cannot perform this action because you do not have permission to modify the Google Cloud SDK installation directory [/opt/google/google-cloud-sdk].

Re-run the command with sudo: sudo /opt/google/google-cloud-sdk/bin/gcloud ...

Exited with code exit status 1

We were trying to install a gcloud plugin (gcloud component install ...).

Currently we use this orb with workaround sudo chown circleci:circleci -R /opt/google.

Expected behavior

Installation succeeded.

gzip: stdin: unexpected end of file

Orb version

circleci/[email protected]

What happened

At Install latest gcloud CLI version, if not available step:

Google Cloud SDK is not installed. Installing it.

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
/tmp/.bash_env-643d6fa05427e83a11edcd7e-0-build: line 1: /tmp/tmp.2PCmvR8IJG/google-cloud-sdk/path.bash.inc: No such file or directory
Failed to install the requested version

Workaround

Retry the job. This worked immediately. Which suggests there's a simple fix for this.

Thanks - V

gcloud component install waiting for user input

Orb version

3.0.1

What happened

When installing the gcloud component it expects the user to input.

Expected behavior

orbs should install the component without any issues.

Any change updating kubectl in cimg:gcp image? It use 1.25 version.

New error in orb: gcloud crashed (ValueError): invalid width 0 (must be > 0) when tagging images

Orb version

circleci/[email protected]

What happened

The following step fails.

IMAGE_TO_TAG="eu.gcr.io/${GOOGLE_PROJECT_ID}/${PROJECT_NAME}:${CIRCLE_SHA1}"
echo Tagging "${IMAGE_TO_TAG}"
gcloud container images add-tag "${IMAGE_TO_TAG}" \
             eu.gcr.io/${GOOGLE_PROJECT_ID}/${PROJECT_NAME}:latest

Echo shows our project

Tagging eu.gcr.io/CHANGED_PROJECT_NAME/data-server:VALID_TAG
ERROR: gcloud crashed (ValueError): invalid width 0 (must be > 0)

Where the project name is valid / exists and the VALID_TAG is visible in the google cloud container registry.

I have tried to run this code from my personal machine and the statement executes without issue.

This workflow has run hundreds of times previously without fail and the most recent commit that triggered it had no changes to the circleci config. The container build and test steps pass without error.

Expected behavior

Image is successfully tagged with latest

Latest version check fails on newer version than patch notes

Orb version

[email protected]

What happened

The runner uses gcr.io/google.com/cloudsdktool/google-cloud-cli:debian_component_based(latest). Google pushes a build here before the patch notes are updated (https://cloud.google.com/sdk/docs/release-notes).

The version installed (432.0.0) differs from the version requested (431.0.0).
Uninstalling v432.0.0...
sudo is required to uninstall the Google Cloud SDK.
Please install it and try again.
Failed to uninstall the current version.

Expected behavior

The latest version is used (from the patch note or local which ever is greater)

`gcp-cli/setup` improperly attempts to uninstall newer versions when requesting latest version

Orb version

3.0.1

What happened

Using the google/cloud-sdk:latest Docker image and running gcp-cli/setup to authenticate, without specifying a version (i.e. defaulting to "latest"), sometimes causes the orb to detect a version mismatch (when the most recent version of the Google Cloud SDK (https://cloud.google.com/sdk/docs/release-notes) is lower than the most recent version of the Docker Hub image (https://hub.docker.com/r/google/cloud-sdk/tags)). This mismatch causes the orb to attempt to uninstall the Google Cloud SDK, but since the Docker image apparently does not include sudo, this fails, and causes the entire pipeline to fail.

This behaviour makes sense when you specify an individual version, but not the blanket "latest" tag.

https://app.circleci.com/pipelines/bitbucket/siqomega/oddsharvester/390/workflows/524dc159-0bac-405b-8744-3ca7006364ad/jobs/866

The version installed (429.0.0) differs from the version requested (428.0.0).
Uninstalling v429.0.0...
sudo is required to uninstall the Google Cloud SDK.
Please install it and try again.
Failed to uninstall the current version.

Expected behavior

If the configuration file requests the latest version of the Google Cloud SDK, a more recent version being preinstalled should not cause the job to try to uninstall the newer version, and instead should continue as normal.

As well, the orb could provide a way to setup an authenticated Google Cloud SDK environment without attempting to install it, if there is already a version installed.

install fails with `sh: unknown operand`

Orb version

2.4.1

What happened

sh: : unknown operand

https://app.circleci.com/pipelines/github/ouihealth/oui-aviva/9552/workflows/529cdd8b-ebc2-40de-998f-a7b2448b685e/jobs/57607

Expected behavior

script shouldn't error with unknown operand. I believe it's a string escaping issue https://stackoverflow.com/a/34251849

error gcloud: command not found

Orb version

v1.0.1

What happened

when I run the steps

steps:
  - gcp-cli/install
  - gcp-cli/initialize

I get the error: error gcloud: command not found

step: Install

the install step seems to have completed without any issue

step: initialize

I get the error: error gcloud: command not found

output:

#!/bin/bash -eo pipefail
# 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

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

# Initialize gcloud CLI
$SUDO gcloud auth activate-service-account --key-file=${HOME}/gcloud-service-key.json
$SUDO gcloud --quiet config set project $GCLOUD_PROJECT_ID
$SUDO gcloud --quiet config set compute/zone $GCLOUD_PROJECT_REGION
sudo: gcloud: command not found
Exited with code 1

Expected behavior

Activated service account credentials for: [ ---CREDENTIAL--- ]
Updated property [core/project].
Updated property [compute/zone].

Notes:

In my account the error started today Feb 26th 2019

Orb tries to install the latest CLI version, even though it's already in the image

Orb version

3.1.1

What happened

We've been using this orb, with the CLI version set to latest and the executor set to gcp-cli/google. However, this leads to an issue every few weeks where either:

Google has updated the Docker image with a new GCP CLI version, but hasn't updated their changelog page
Google has updated their changelog page with a new GCP CLI version, but hasn't released an updated Docker image

When that happens, our deploys are blocked with an error along these lines:

The version installed (451.0.0) differs from the version requested (451.0.1).
Uninstalling v451.0.0...
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

There's no way to get past this, unless we hard-set the CLI version to whatever's in the Docker image. This is frequently leading to our deploys being blocked for hours, sometimes up to a day.

In our case, we'd be more than happy to simply use whatever version is provided by the latest Google Cloud SDK docker image. We know it'll be the newest version the vast majority of the time, and if it's not the newest version, it'll be very, very close. And the docs for this orb's install command suggest that this is the intended behaviour (emphasis mine):

  Install the gcloud CLI. **When installing within the Docker executor, the
  install will only occur if the CLI isn't already installed.** If installing in
  a Linux machine image, it will remove the pre-installed version and instead
  install the version specified by this orb.

Expected behavior

When using the gcp-cli/google executor and the latest version is specified for the CLI, don't try to uninstall/reinstall a different version, because doing so will always fail with permission errors anyway.

(I'd be happy enough to put together a PR for this, but I wanted to open the discussion first to make sure I wouldn't be wasting any work putting forward a fix for this)

3.x `install` fails in Windows executors

Orb version

3.x.x

What happened

Install fails with:

-VThe system cannot find the file specified.

Exited with code exit status 1

Expected behavior

Orb should check for existing installation (it is already included) and should probably run gcloud components update instead of install.

Install fails on host without passwordless sudo

Orb version

v2.4.1

What happened

gcp-cli-orb/src/scripts/install.sh

Line 21 in 66dafec

sudo rm -rf /opt/google-cloud-sdk

cleanup fails on image without passwordless sudo.

----------------------------------------------------------------------------------------------------
this is a machine executor job, replacing default installation of gcloud CLI
----------------------------------------------------------------------------------------------------
[sudo] password for cnb:

Expected behavior

The orb can attempt to cleanup but should not error when cleanup fails.

In this case, /opt/google-cloud-sdk don't even exist.

gcloud command not found after upgrading to 1.8.4 from 1.3.0

Orb version

Upgraded from 1.3.0 to 1.8.4

What happened

I'm having an issue with deployment so I SSH'ed into the job to figure out what's going on. I immediately found that the gcloud command no longer is available on the CLI. If I type gcloud --version I get a "command not found" error.

I did find, however, that there is a google-cloud-sdk directory in the root, which contains the executable. So I can run the command via ./google-cloud-sdk/bin/gcloud. But this is tedious.

Expected behavior

Ideally, it would work as it did before. I suppose all that really needs to happen is for the new gcloud location to be added to the $PATH. However it's done, it's important to be able to SSH into the job and troubleshoot using the initialized gcloud command.

Installing gcloud SDK in project root will cause some linting jobs failed

Issue

Installing gcloud SDK in project root will cause linting jobs failed.

In our case, our tool will scan all file with pattern (like *.js, *.cjs) and run linting rules. But this will cause the linting tool is scanning not only target project's code but also gcloud SDK's code. And gcloud's code is written in different coding style from us, this will cause the linting tool always fail.

Request

Allow user to pass the install location as parameter.

gcp-cli-orb/src/scripts/install.sh

Line 7 in 67e4448

base_dir="$(printf '%s\n' "$CIRCLE_WORKING_DIRECTORY" | sed "s/~/$home/")"

Or just install at home directory like version 2.4.1.

region / zone should not be required

Orb version

circleci/[email protected] (current)

What happened

https://circleci.com/developer/orbs/orb/circleci/gcp-cli#commands-initialize
lists all the env vars as not required. They are technically optional, since they have defaults, but the job will fail if the env vars themselves are not set.

Expected behavior

I should not have to provide a region or zone to use this command (the module should not fail, but simply not set those values)
The docs should make it clear that the variables are the env var holding the value, vs. the place you set the value itself (admittedly, the variable type is env_var_name).

install: Fails on Alpine

Orb version

1.8.5

What happened

install () {
  # 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
  cd ~/
  curl -Ss --retry 5 https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-283.0.0-linux-x86_64.tar.gz | tar xz
  echo 'source ~/google-cloud-sdk/path.bash.inc' >> $BASH_ENV
}

if grep 'docker\|lxc' /proc/1/cgroup > /dev/null 2>&1; then
  if [[ $(command -v gcloud) == "" ]]; then
    install
  else
    echo "gcloud CLI is already installed."
  fi
else
  echo "----------------------------------------------------------------------------------------------------"
  echo "this is a machine executor job, replacing default installation of gcloud CLI"
  echo "----------------------------------------------------------------------------------------------------"
  sudo rm -rf /opt/google-cloud-sdk
  install
fi

sh: : unknown operand
gcloud CLI is already installed.

CircleCI received exit code 0

Expected behavior

It should work on alpines default shell (busybox). If the script requires bash it should set that in the hashbang.

Gcloud config set project VALUE fails as VALUE comes back empty

Orb version

2.1.0

What happened

Init job is failing when trying to substitute environment variables. Snippet of code where this is happening:

        # Store service account
        echo $<<parameters.gcloud-service-key>> > ${HOME}/gcloud-service-key.json
        # Initialize gcloud CLI
        gcloud auth activate-service-account --key-file=${HOME}/gcloud-service-key.json
        gcloud --quiet config set project $<<parameters.google-project-id>>
        if [[ -n $<<parameters.google-compute-zone>> ]]; then
          gcloud --quiet config set compute/zone $<<parameters.google-compute-zone>>
        elif [[ -n $<<parameters.google-compute-region>> ]]; then
          gcloud --quiet config set compute/region $<<parameters.google-compute-region>>
        else
          echo "ERROR: Set <<parameters.google-compute-zone>> or <<parameters.google-compute-region>> env variable" >&2
          exit 1
        fi

Specifically at this line:

gcloud --quiet config set project $<<parameters.google-project-id>>

CircleCI output is as follows:

Activated service account credentials for: [redacted]


Updates are available for some Cloud SDK components.  To install them,
please run:
  $ gcloud components update

ERROR: (gcloud.config.set) argument VALUE: Must be specified.
Usage: gcloud config set SECTION/PROPERTY VALUE [optional flags]
  optional flags may be  --help | --installation

For detailed information on this command and its flags, run:
  gcloud config set --help

Exited with code exit status 2

Should the variable substitution for the parameters not be defined like this instead:

${<< parameter.google-project-id >>} , which circle will then actually read in from the project defined env variables?

Job which runs this command has parameters defined as such:

parameters:
      gcp-service-key:
        type: env_var_name
        default: GCLOUD_SERVICE_KEY_D1
      gcp-project-id:
        type: env_var_name
        default: GCLOUD_PROJECT_ID_D1
      gcp-storage:
        type: env_var_name
        default: GOOGLE_STORAGE_D1

and the orb command is invoked like this:

...
steps:
  - gcp-cli/install
  - gcp-cli/initialize:
      gcloud-service-key: << parameters.gcp-service-key >>
      google-project-id: << parameters.gcp-project-id >>
...

Expected behavior

The substituion of variables passed into the orb command should not be null but rather contain the value of the specified in the project settings env variable, meaning when gcloud --quiet config set project $<<parameters.google-project-id>> is invoked, $<<parameters.google-project-id>> doesn't come back empty.

Authentication issue to push images to GCP

Orb version

1.8.2

What happened

when pushing to GCR on GCP when have this issue:

docker push eu.gcr.io/$GOOGLE_PROJECT_ID/path/to/pr/module:$sha1

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

current workaround is:

echo $GCLOUD_SERVICE_KEY > ${HOME}/gcp-key.json
            set -x
            gcloud auth activate-service-account --key-file ${HOME}/gcp-key.json
            gcloud --quiet config set project ${GOOGLE_PROJECT_ID}
            gcloud auth configure-docker --quiet --project $GOOGLE_PROJECT_ID
            gcloud info

circleci-public / gcp-cli-orb Goto Github PK

gcp-cli-orb's Introduction

GCP CLI Orb

Usage

Contributing

gcp-cli-orb's People

Contributors

Stargazers

Watchers

Forkers

gcp-cli-orb's Issues

Orb version

Orb version

What happened

Expected behavior

Notes

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Additional Notes

Orb version 2.4.1

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Workaround

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

step: Install

step: initialize

Expected behavior

Notes:

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior

Orb version

What happened

Expected behavior