Repository navigation
Can we make gcloud-node auto-detect the projectId if it's in a special environment? #974
Description
Activity
App Engine via Managed VMs
I believe so, because it's available as an env var, right?
GAE_LONG_APP_ID, possibly.Compute Engine
I believe you have to hit the metadata server, which complicates this for us, as that is an async operation.
We talked about this in #570 (shortcut: #570 (comment)).
What we came up with was... for the same code to go from a dev environment where a project ID will always be required (can't be autodetected) to a production requirement (where it can be autodetected), the user would already have been providing the project ID in dev, only to remove it when pushing to production for the benefit of magic autodetection.
So the resolution was to just require it explicitly, but honor a generic env var "
GCLOUD_PROJECT_ID". I'm not sure what happened to that... I don't think we ever did honor that env var or document it. But then this issue came along, and afaik, it doesn't look like we decided on one yet?If we can agree on just a single env var like "GCLOUD_PROJECT_ID", do you still think that's a good way to go for all the reasons we discussed in #570?
Effectively we're saying to run this to start your app, and this problem goes away, right ?
$ export GCLOUD_PROJECT=`curl -L http://metadata.google.internal/computeMetadata/v1beta1/project/project-id` $ node
Yeah that would definitely work (naming of "GCLOUD_PROJECT" tbd).
Sure -- I think that was the latest proposal in that issue on gcloud-common-private.
Okay cool, I'll get that supported asap!
- added a commit that references this issue
on Jul 23, 2025 - added a commit that references this issue
on Jan 28, 2026 - added a commit that references this issue
on Feb 17, 2026 - added a commit that references this issue
on Mar 5, 2026 - added a commit that references this issue
on Mar 18, 2026
Special environment = Compute Engine or App Engine via Managed VMs?