feat: add Google Cloud CLI (gcloud)#271
Merged
Merged
Conversation
Fills the multi-cloud parity gap - AWS and Azure CLIs were already present, GCP wasn't. Installed via the official tarball + install.sh (non-interactive, usage-reporting/path-update/command-completion disabled) rather than apt, since Google's rapid-channel distribution isn't structured the same way azure-cli's apt repo is; the install script reuses the system Python 3.12 already on PATH rather than bundling its own runtime. - Wired into the existing version-check/version-sync automation. Unlike the other CLIs, gcloud isn't GitHub-hosted, so check_latest_version.py gets a dedicated check_gcloud_version() that reads the same rapid-channel components-2.json manifest gcloud itself uses to check for updates. - `gcloud --version` needs no auth, so it's added as a real smoke test in samples/run_sample.sh (same treatment as gh/kubectl/helm), unlike awscli/azurecli which stay documentation-only since they need live credentials to demonstrate anything. - New docs/usage/gcloudcli_usage.md follows the existing per-tool usage doc pattern. Note: this is a noticeably heavier install than the other CLIs (~88 MB compressed download) - a known, accepted tradeoff for closing the GCP gap.
Same shape of issue as azure-cli's /opt/az venv, plus a new one from gsutil's vendored dependencies: - gcloud bundles its own Python under platform/bundledpythonunix with its own pinned cryptography==46.0.7 (vulnerable OpenSSL, GHSA-537c-gmf6-5ccf), separate from the system pip environment already patched. Discover the bundled interpreter with `find` rather than hardcoding its exact filename, since the bundled-python archive layout isn't something we control. - gsutil vendors urllib3's entire source tree, including urllib3's own test-only dummy TLS server fixtures under third_party/urllib3/dummyserver/certs/. Those are checked-in dummy RSA private keys used only by urllib3's own test suite - Trivy's secret scanner (which runs independent of the vuln-type filter) flagged them as real private keys. They're dead weight in this image regardless, so delete the whole dummyserver directory instead of just suppressing the alert.
The previous fix used --upgrade, which let pip cascade-upgrade other packages (most likely cffi) in gcloud's bundled Python to satisfy cryptography's declared constraints. That broke the interpreter itself: gcloud errored with "problems with your Python interpreter" on every invocation, failing the version-verify CI step. gcloud's bundled Python is a tightly pinned snapshot, not a general venv - installing cryptography with --no-deps --force-reinstall touches only that one package's files and leaves everything else in the snapshot alone.
Neither of the previous two attempts touched pyOpenSSL, since it's a
*dependent* of cryptography, not a dependency - pip has no reason to
touch it when only cryptography is named on the install line,
--no-deps or not. gcloud vendors pyOpenSSL too, and it imports
cryptography's internal OpenSSL binding attributes directly, so a
cryptography-only bump left it calling attributes that no longer
exist ("AttributeError: module 'lib' has no attribute 'GEN_EMAIL'"),
breaking gcloud's own bootstrap (gcloud_main imports
oauth2client -> pyOpenSSL transitively).
pyOpenSSL 26.3.0 declares cryptography<50,>=49.0.0 as its constraint,
which the already-pinned cryptography==49.0.0 satisfies - installing
both together, still with --no-deps, keeps the rest of gcloud's
pinned snapshot untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
gcloud) to the toolkit, closing the multi-cloud parity gap (AWS + Azure CLIs already present, GCP wasn't).install.sh(--quiet --usage-reporting=false --path-update=false --command-completion=false --rc-path=/dev/null) rather than apt — Google's rapid-channel distribution isn't set up the same way Microsoft's azure-cli apt repo is. The installer detects and reuses the system Python 3.12 already onPATHrather than bundling its own runtime (unlike azure-cli, which vendors a private Python).check_latest_version.pygets a dedicatedcheck_gcloud_version()that reads the samerapidchannelcomponents-2.jsonmanifestgclouditself uses internally to check for updates.gcloud --versionneeds no auth, so it's a real smoke test insamples/run_sample.sh(same treatment asgh/kubectl/helm), rather than documentation-only like AwsCLI/AzureCLI which need live credentials to demonstrate anything useful.docs/usage/gcloudcli_usage.mdfollows the existing per-tool usage doc pattern.Known tradeoff: this is a noticeably heavier install than the other CLIs (~88 MB compressed download, larger on disk) — flagged and accepted up front since it's the price of closing the GCP gap.
Test plan
Docker Image CIbuilds cleanly andgcloud --versionpasses as part of the sample smoke testTrivygate passesgcloud auth login/gcloud projects listinside the built image