Is there a better way to set a gcloud project in a directory?

Viewed 1836

I work on multiple appengine projects in any given week. i.e. assume multiple clients. Earlier I could set application in app.yaml. So whenever I did appcfg.py update.... it would ensure deployment to the right project.

When deploying, the application variable throws an error with gcloud deploy. I had to use gcloud app deploy --project [YOUR_PROJECT_ID]. So what used to be a directory level setting for a project, is now going into our build tooling. And missing out that simple detail can push a project code to the wrong customer. i.e. if I did gcloud config set project proj1 and then somehow did a gcloud app deploy in proj2, it would deploy to proj1. Production deployments are done after detailed verification on the build tools and hence it is less of an issue there because we still use the --project flag.

But its hard to do similar stuff on the development environment. dev_appserver.py doesn't have a --project flag. When starting dev_appserver.py I've to do gcloud config set project <project-id> before I start the server. This is important when I using stuff like PubSub or GCS (in dev topics or dev buckets).

Unfortunately, missing out a simple configuration like setting a project ID in a dev environment can result into uploading blobs/messages/etc into the wrong dev gcs bucket or wrong dev pubsub topic (not using emulators). And this has happened quite a few times especially when starting new projects.

I find the above solutions as hackish-workarounds. Is there a good way to ensure that we do not deploy or develop in a wrong project when working from a certain directory?

4 Answers

I've had this problem for years and I believe I found a decent compromise.

  1. Create a simple script called contextual-gcloud. Note the \gcloud, fundamental for future aliasing.
$ cat > contextual-gcloud 
#!/bin/bash

if [ -d .gcloudconfig/ ]; then
    echo "[$0] .gcloudconfig/ directory detected: using that dir for configs instead of default."
    CLOUDSDK_CONFIG=./.gcloudconfig/ \gcloud "$@"
else
    \gcloud "$@"
fi
  1. Add to your .bashrc and reload / start new bash. This will fix autocompletion.

    alias gcloud=contextual-gcloud

  2. That's it! If you have a directory called that way the system will use that instead, which means you can load your configuration into source control etc.. only remember to git ignore stuff like logs, and private stuff (keys, certificates, ..).

Note: auto-completion is fixed by the alias ;)

Code: https://github.com/palladius/sakura/blob/master/bin/contextual-gcloud

There's a very nice way I've been using with PyCharm, I suspect you can do so with other IDEs.

You can declare the default env variables for the IDE Terminal, so when you open a new terminal gcloud recognises these env variables and sets the project and account.

pycharm preferences config terminal env variables

No need to switch configurations between projects manually (gcloud config configurations activate ). Terminals open in other projects will inherit it's own GCP project and config from the ENV variables.

Related