Google Cloud Shell gcloud commands output not pretty printed anymore - google-cloud-platform

I was using GCloud Shell a few weeks ago and got pretty printed outputs from gcloud commands, like so:
DISPLAY NAME EMAIL DISABLED
Compute Engine default service account XXXXXXXXXXXX-compute#developer.gserviceaccount.com False
sa-xxxxxxxxx sa-xxxxxxxxx#my-project.iam.gserviceaccount.com False
Since a few days, output is not anymore pretty printed:
DISPLAY NAME: Compute Engine default service account
EMAIL: XXXXXXXXXXXX-compute#developer.gserviceaccount.com
DISABLED: False
DISPLAY NAME: sa-xxxxxxxxx
EMAIL: sa-xxxxxxxxx#my-project.iam.gserviceaccount.com
DISABLED: False
I checked embedded gcloud SDK version:
$ gcloud -v
Google Cloud SDK 360.0.0
alpha 2021.10.04
app-engine-go 1.9.71
app-engine-java 1.9.91
app-engine-python 1.9.95
app-engine-python-extras 1.9.95
beta 2021.10.04
bigtable
bq 2.0.71
cbt 0.10.1
cloud-build-local 0.5.2
cloud-datastore-emulator 2.1.0
core 2021.10.04
datalab 20190610
gsutil 5.3
kind 0.7.0
kpt 1.0.0-beta.5
local-extract 1.3.1
minikube 1.23.2
pubsub-emulator 0.5.0
skaffold 1.32.0
I also checked the documentation on output formats, which isn’t of any help. Tried several outputs without being able to have a pretty one like before.
I tried installing the SDK 360.0.0 on Cloud Shell, which gives me the pretty output as before…
Anyone else having this issue? Or knowing how to get the pretty print as before (without having to manually install gcloud SDK)?
Edit:
As asked by John Hanley, here is the output of gcloud config list:
[accessibility]
screen_reader = True
[component_manager]
disable_update_check = True
[compute]
gce_metadata_read_timeout_sec = 30
[core]
account = nicolas#mydomain.com
disable_usage_reporting = True
project = my-project
[metrics]
environment = devshell
Your active configuration is: [cloudshell-25102]
Column width as given by tput cols is 267.

Thanks to #JohnHanley for the insight of gcloud config list, I compared the configurations between embedded gcloud and the downloaded version, then read some documentation to find that this behavior is only due to an accessibility option which is now set to true by default.
For anyone having this issue, here is the command to get the good ol' pretty print output back:
gcloud config set accessibility/screen_reader false
If you want it to persist between Cloud Shell reboots, add the --installation flag and use sudo.

Related

Error while trying to authenticate with `gcloud init`

I am trying to athenticate to the gcloud sdk using : gcloud init.
I get a URL I'm supposed to access in order to copy a token and return it to the CLI... but instead of a token, I get this error :
Erreur d'autorisation
Erreur 400 : invalid_request
Missing required parameter: redirect_uri
Is this a bug?
gcloud version info:
Google Cloud SDK 377.0.0
alpha 2022.03.10
beta 2022.03.10
bq 2.0.74
bundled-python3-unix 3.8.11
core 2022.03.10
gsutil 5.8
I am running gcloud init on wsl2 (Ubuntu 18.04). This error occurs right after the installation of gcloud with sudo apt install google-cloud-sdk.
I had the same problem and gcloud has slightly changed the way their auth flow works.
Run gcloud auth login and then copy the whole output (not just the URL) to a terminal on a computer that has both a web browser and gcloud CLI installed. The command you should copy looks like
gcloud auth login --remote-bootstrap="https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=****.apps.googleusercontent.com&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&state=****&access_type=offline&code_challenge=****&code_challenge_method=S256&token_usage=remote"
When you run that on your computer that has a web browser, it will open a browser window and prompt you to log in. Once you authorize your app in the web browser you get a new URL in your terminal that looks like
https://localhost:8085/?state=****&code=****&scope=email%20openid%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/cloud-platform%20https://www.googleapis.com/auth/appengine.admin%20https://www.googleapis.com/auth/compute%20https://www.googleapis.com/auth/accounts.reauth&authuser=0&hd=****&prompt=consent
Paste this new URL back into the prompt in your headless machine after Enter the output of the above command: (in your case, this would be in your WSL2 terminal). Press enter and you get the output
You are now logged in as [****].
Your current project is [None]. You can change this setting by running:
$ gcloud config set project PROJECT_ID
[8]+ Done code_challenge_method=S256
Try
gcloud init --console-only
Then you will get the url which will work.
You must log in to continue. Would you like to log in (Y/n)? y
WARNING: The --[no-]launch-browser flags are deprecated and will be removed on June 7th 2022 (Release 389.0.0). Use --no-browser to replace --no-launch-browser.
Go to the following link in your browser:
https://accounts.google.com/o/o....
update 2022-06-20. option console-only is removed for version 389.0.0.
So instead use
gcloud init --no-browser
There are some workarounds and they depend on your particular Windows environment.
In this post and in this one you can check the most related issues with respect to gcloud running in WSL.
Here you can find some Google groups related threads that might be helpful.
Finally, you could check some related Windows troubleshootings that can help in issues related to WSL2 on your own environment.
EDIT:
it seems this answer and the one from #K.I. give other commands that don't rely on implementation details. I've tested those 3 commands:
gcloud init --console-only
gcloud auth login --no-launch-browser
gcloud init --no-launch-browser
Original answer, another workaround (17/07/2022):
DISPLAY=":0" gcloud auth login
is a workaround mentioned in this issue. Instead of requiring you to install gcloud CLI outside WSL2, it pretends there is a browser.
A link is printed, click it, login on your browser, and you're authenticated with the CLI.
Then run again gcloud init.
You can do it without error by using another method of gcloud installation :
curl https://sdk.cloud.google.com | bash
exec -l $SHELL #restart shell
gcloud init

How can I run beta gcloud component like "gcloud beta artifacts docker images scan" within Cloud Build?

I am trying to include the Container Analyis API link in a Cloud Build pipeline.This is a beta component and with command line I need to install it first:
gcloud components install beta local-extract
then I can run the on demand container analyis (if the container is present locally):
gcloud beta artifacts docker images scan ubuntu:latest
My question is how I can use component like beta local-extract within Cloud Build ?
I tried to do a fist step and install the missing componentL
## Update components
- name: 'gcr.io/cloud-builders/gcloud'
args: ['components', 'install', 'beta', 'local-extract', '-q']
id: Update component
but as soon as I move to the next step the update is gone (since it is not in the container)
I also tried to install the component and then run the scan using (& or ;) but it is failling:
## Run vulnerability scan
- name: 'gcr.io/cloud-builders/gcloud'
args: ['components', 'install', 'beta', 'local-extract', '-q', ';', 'gcloud', 'beta', 'artifacts', 'docker', 'images', 'scan', 'ubuntu:latest', '--location=europe']
id: Run vulnaribility scan
and I get:
Already have image (with digest): gcr.io/cloud-builders/gcloud
ERROR: (gcloud.components.install) unrecognized arguments:
;
gcloud
beta
artifacts
docker
images
scan
ubuntu:latest
--location=europe (did you mean '--project'?)
To search the help text of gcloud commands, run:
gcloud help -- SEARCH_TERMS
so my question are:
how can I run "gcloud beta artifacts docker images scan ubuntu:latest" within Cloud Build ?
bonus: from the previous command how can I get the "scan" output value that I will need to pass as a parameter to my next step ? (I guess it should be something with --format)
You should try the cloud-sdk docker image:
https://github.com/GoogleCloudPlatform/cloud-sdk-docker
The Cloud Build team (implicitly?) recommends it:
https://github.com/GoogleCloudPlatform/cloud-builders/tree/master/gcloud
With the cloud-sdk-docker container you can change the entrypoint to bash pipe gcloud commands together. Here is an (ugly) example:
https://github.com/GoogleCloudPlatform/functions-framework-cpp/blob/d3a40821ff0c7716bfc5d2ca1037bcce4750f2d6/ci/build-examples.yaml#L419-L432
As to your bonus question. Yes, --format=value(the.name.of.the.field) is probably what you want. The trick is to know the name of the field. I usually start with --format=json on my development workstation to figure out the name.
The problem comes from Cloud Build. It cache some often used images and if you want to use a brand new feature in GCLOUD CLI the cache can be too old.
I performed a test tonight, the version is 326 in cache. the 328 has just been released. So, the cached version has 2 weeks old, maybe too old for your feature. It could be worse in your region!
The solution to fix this, is to explicitly request the latest version.
Go to this url gcr.io/cloud-builders/gcloud
Copy the latest version
Paste the full version name in the step of your Cloud Build pipeline.
The side effect is a longer build. Indeed, because this latest image isn't cached, it has to be downloaded in Cloud Build.

gcloud project id in node.js error is different from gcloud set project id?

I'm trying to get Google Cloud Vision to work with node.js by following their documentation here. Although I keep getting:
PERMISSION_DENIED: Cloud Vision API has not been used in project 5678.. before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/vision.googleapis.com/overview?project=5678.. then retry
To note though the project number is very different from what I see in gcloud's output when I gather information from the following commands:
gcloud info |tr -d '[]' | awk '/project:/ {print $2}'
'my-set-project' <=== set project id in use
gcloud projects list
which outputs:
PROJECT_ID='my-set-project' // <=== Same id as "gcloud info" command
NAME='my-project-name'
PROJECT_NUMBER=1234.. // <===== Different number from Node.js Error
I have already enabled the api, downloaded a service key and setup the export GOOGLE_APPLICATION_CREDENTIALS=[path/to/my/service/key]. But right now I believe that the service key linkup is not the issue yet as I have not yet really have had gcloud pointing to 'my-set-project'.
I have also found a default.config at
cat /Users/My_Username/.config/gcloud/application_default_credentials.json
which has:
{
"client_id": "5678..-fgrh // <=== same number id as node.js error
So how can I get gcloud-cli to switch to project "1234" which has the API enabled there? I thought doing the command:
gcloud config set project 'my-set-project'
would get running node apps using gcp to use the project of '1234' instead of the default '5678'. Any help will be appreciated as I'm still getting used to the gcloud-cli. Thanks
Try:
gcloud auth activate-service-account --key-file=/path/to/your/service_account.json

Google Cloud - Wrong project id being used from different email address

Despite running gcloud auth application-default login and gcloud config set core/project CORRECT_PROJECT_ID the project keeps defaulting to an incorrect project id:
gcloud config list
[core]
account = CORRECT_EMAIL
disable_usage_reporting = True
project = CORRECT_PROJECT_ID
Your active configuration is: [default]
I can successfully run the sample code from the tutorial (below) if I run in the terminal
export GOOGLE_APPLICATION_CREDENTIALS="[PATH]"
However, I didn't want to have to do this every time, so I ran the command:
gcloud auth application-default login
This opened a browser with a list of my gmail accounts, and even though I selected the correct account, the success window went to a different gmail account. So then I tried it in an incognito window, and it worked.
However, running npm start resulted in the following error:
ERROR: { Error: 7 PERMISSION_DENIED: Cloud Natural Language API has not been used in project WRONG_PROJECT_ID before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/language.googleapis.com/overview?project=WRONG_PROJECT_ID then retry.
Then I ran gcloud config set core/project CORRECT_PROJECT_ID and got the message Updated property [core/project].
When I run npm start I get the same message:
ERROR: { Error: 7 PERMISSION_DENIED: Cloud Natural Language API has not been used in project WRONG_PROJECT_ID before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/language.googleapis.com/overview?project=WRONG_PROJECT_ID then retry.
I tried gcloud auth login and got the following message (after I authenticated in an incognito window):
WARNING: `gcloud auth login` no longer writes application default credentials.
If you need to use ADC, see:
gcloud auth application-default --help
You are now logged in as [CORRECT EMAIL ADDRESS].
Your current project is [CORRECT_PROJECT_ID]. You can change this setting by running:
$ gcloud config set project PROJECT_ID
I have a few suggestions that may correct this behaviour.
1) Clear your web browser cache & cookies. Then run "gcloud auth application-default login"
2) Try re-installing the gcloud toolkit.
3) Try unsetting the project in your config first, then set the project to the correct project. i.e.
gcloud config unset project WRONG_PROJECT_ID
gcloud config set project CORRECT_PROJECT_ID
4) Check the “CLOUDSDK_CORE_PROJECT” environment variable. Set it to the correct project if it is not already.
5) Try re-running “gcloud init”
6) You can find your application default credentials in
Linux: ~/.config/gcloud/application_default_credentials.json
Windows: C:\Users\%username%\AppData\Roaming\gcloud\credentials
You can delete the file, & regenerate it using commands you had mentioned in your question such as “gcloud auth default-credentials login”
We need to find where npm start is getting its credentials from. Once we figure that out, we can figure out how to change it, & understand why it’s looking there etc.
Are you able to find the config file to see where it is looking for credentials?
Is npm start the entire command? I’m not too familiar with Node JS. I’m not sure why it is trying to use Natural Language API.
You also mentioned a tutorial but I think you may have forgotten to include it in your question. Which tutorial are you referring to?

ERROR: gcloud crashed (TypeError): setproxy() takes at most 7 arguments (8 given)

Both gcloud auth login and gcloud compute --project XXX ssh --zone YYY ZZZ printed the error message in the title.
ERROR: gcloud crashed (TypeError): setproxy() takes at most 7 arguments (8 given)
The gcloud version is
Google Cloud SDK 186.0.0
bq 2.0.28
core 2018.01.22
gsutil 4.28
gcloud auth login has worked before the upgrade to 186.0.0 (from 182.0.0). All of gcloud has worked some time previously. To double-check, the proxy has been set:
gcloud config set proxy/address 127.0.0.1
gcloud config set proxy/port 8080
gcloud config set proxy/type http
but this has not changed anything (proxy is set via environment variables anyways).
https_proxy=http://127.0.0.1:8080
http_proxy=http://127.0.0.1:8080
UPDATE: The error has persisted even after removing the config directory ~/.config/gcloud. There's an issue at https://issuetracker.google.com/issues/72407295.
How can this be fixed?
As a workaround, downgrading to 185 solved the issue:
Go to https://storage.cloud.google.com/cloud-sdk-release, type "google-cloud-sdk-185" into the search bar, download the file for your OS, unzip, etc. You need to use a new shell to unset the change to the PATH that gcloud did.
It has been fixed in 187:
We've found a fix; expect it in the 187.0.0 Cloud SDK release next week.
Update Version 187 has been released: Download at https://cloud.google.com/sdk/downloads#versioned. This also gives the message
To revert your SDK to the previously installed version, you may run:
$ gcloud components update --version 185.0.0
after upgrade, so that could be used to revert as well, if similar problems occur.