maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/cmd/stack_select.go

38 lines
991 B
Go
Raw Normal View History

Clarify aspects of using the DCO
2017-06-26 23:46:34 +02:00
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
package cmd
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
import (
Have the CLI keep track of the current environment Previously, the engine was concered with maintaing information about the currently active environment. Now, the CLI is in charge of this. As part of this change, the engine can now assume that every environment has a non empty name (and I've added asserts on the entrypoints of the engine API to ensure that any consumer of the engine passes a non empty environment name)
2017-10-03 01:37:12 +02:00
"fmt"
Use tokens.QName instead of string as the type for environment Internally, the engine deals with tokens.QName and not raw strings. Push that up to the API boundary
2017-10-03 00:14:55 +02:00
"github.com/pulumi/pulumi/pkg/tokens"
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
"github.com/spf13/cobra"
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
"github.com/pulumi/pulumi/pkg/util/cmdutil"
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
)
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
func newStackSelectCmd() *cobra.Command {
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
return &cobra.Command{
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
Use: "select [<stack>]",
Short: "Switch the current workspace to the given stack",
Long: "Switch the current workspace to the given stack. This allows you to use\n" +
Renames: `plan` -> `preview`, `deploy` -> `push`. Part of #353. These changes also remove all command aliases from the `pulumi` command.
2017-09-23 00:15:42 +02:00
"other commands like `config`, `preview`, and `push` without needing to specify the\n" +
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
"stack name each and every time.\n" +
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
"\n" +
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
"If no <stack> argument is supplied, the current stack is printed.",
Refactor shared command bits into pkg/cmdutil This paves the way for more Go-based command line tools that can share some of the common utility functions around diagnostics and exit codes.
2017-04-12 20:12:25 +02:00
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
// Read in the name of the stack to switch to.
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
if len(args) == 0 {
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
name, err := getCurrentStack()
Have the CLI keep track of the current environment Previously, the engine was concered with maintaing information about the currently active environment. Now, the CLI is in charge of this. As part of this change, the engine can now assume that every environment has a non empty name (and I've added asserts on the entrypoints of the engine API to ensure that any consumer of the engine passes a non empty environment name)
2017-10-03 01:37:12 +02:00
if err != nil {
return err
}
fmt.Printf("%v\n", name)
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
}
Prepare for moving command implementations to the engine The plan is to take all the logic that actually implements the commands exposed by `lumi` into a helper type that can be used by both `lumi` and the Pulumi Service. This is step one, which was to decouple the implementation of these commands from the command line parsing and CLI interface they are presented to the user from.
2017-08-23 01:23:50 +02:00
Use `Stack` over `Environment` to describe a deployment target Previously we used the word "Environment" as the term for a deployment target, but since then we've started to use the term Stack. Adopt this across the CLI. From a user's point of view, there are a few changes: 1. The `env` verb has been renamed to `stack` 2. The `-e` and `--env` options to commands which operate on an environment now take `-s` or `--stack` instead. 3. Becase of (2), the commands that used `-s` to display a summary now only support passing the full option name (`--summary`). On the local file system, we still store checkpoint data in the `env` sub-folder under `.pulumi` (so we can reuse existing checkpoint files that were written to the old folder)
2017-10-16 21:04:35 +02:00
return setCurrentStack(tokens.QName(args[0]), true)
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
}),
}
}
Reference in a new issue Copy permalink