GCloud: Changing the default project (in a nutshell)

gcloud command line tool allow us managing a list of Google Cloud projects, one of which is considered as the default project, so all the operations we perform via gcloud are performed on it.

Available projects

To check what projects are available via gcloud, run the command:

$ gcloud projects list

This command drops an output similar to this example:

PROJECT_ID	NAME		PROJECT_NUMBER
fooOrg-pr01	Project Bar	239785793387
fooOrg-pr02	Project Zaz	348328582382
...

You can check the available options in the GCloud SDK reference.

Current default project

As you can see, that output doesn't set what is the default project. To get it run this command:

$ gcloud config get-value project

The command output will show the ID of the default project. Following the above example, the output of the command could be fooOrg-pr01 to state that the default project is our Project Bar.

Changing the current default project

To change the default project, run this command:

$ gcloud config set project <project-ID>

So following the previous example, to set our Project Zaz as default, this command should be run:

$ gcloud config set project fooOrg-pr02

Comentarios

Entradas populares de este blog

Linting C# in Visual Studio Code

Though very usual in programming environments as Javascript/Typescript, linting , or analyzing code for enforcing a set of coding style rules, is not usually present in the .NET based environments. Rule enforcing is really useful when working on team shared codebases in order to keep them coherent, what in last term reduces both development times and coding errors. A linting example Maybe a practical example would be helpful for explaining what linting is to the newcomers (feel free to go on if you aren't). Let's imagine you are a new member in a C# development team that has well established set of coding style rules. Instead (or apart) of putting them in a document, they've adopted a tool that checks these rules during the code building process. Your first code is such ambitious as this: namespace HelloWorld { using System; public class Program { public static void Main(string[] args) { Console

ESlint: Ignore unused underscore variables

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define

Using Bitbucket app passwords with git on MacOS (OSX)

Learn how Bitbucket passwords are stored by git on MacOS.

The Modern Programmer

Buscar este blog