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

81 lines
2.9 KiB
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.
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +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
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
import (
"github.com/spf13/cobra"
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
"github.com/pulumi/pulumi/pkg/engine"
"github.com/pulumi/pulumi/pkg/util/cmdutil"
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
)
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
func newPreviewCmd() *cobra.Command {
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
var analyzers []string
Add a --debug option to plan, deploy, and destroy This change introduces a --debug option to the plan, deploy, and destroy commands. Unlike --logtostderr, which merely hooks into the copious Glogging that we perform (and is therefore meant for developers of the tools themselves and not end users), --debug hooks into the user-facing debug stream. This now includes any debug messages coming from the resource providers as they perform their tasks.
2017-07-14 02:09:46 +02:00
var debug bool
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
var stack string
Switch to a --parallel=P flag This change flips the polarity on parallelism: rather than having a --serialize flag, we will have a --parallel=P flag, and by default we will shut off parallelism. We aren't benefiting from it at the moment (until we implement pulumi/pulumi-fabric#106), and there are more hidden dependencies in places like AWS Lambdas and Permissions than I had realized. We may revisit the default, but this allows us to bite off the messiness of dependsOn only when we benefit from it. And in any case, the --parallel=P capability will be useful.
2017-09-17 17:10:46 +02:00
var parallel int
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
var showConfig bool
Prettify the CLI in a few places This changes a few things in the CLI, mostly just prettying it up: * Label all steps more clearly with the kind of step. Also unify the way we present this during planning and deployment. * Summarize the changes that *did not* get made just as clearly as those that did. In other words, stuff like this: info: 2 resources changed: +1 resource created -1 resource deleted 5 resources unchanged and info: no resources required 5 resources unchanged * Always print output properties when they are pertinent. This includes creates, replacements, and updates. * Show replacement creates and deletes very distinctly. The create parts show up minty green and the delete parts show up rosey red. These are the "physical" steps, compared to the "logical" step of replacement (which remains marigold). I still don't love where we are here. The asymmetry between planning and deployment bugs me, and could be surprising. ("Hey, my deploy doesn't look like my plan!") I don't know what developers will want to see here and I feel like in general we are spewing far too much into the CLI to make it even useful for anything but diagnosing failures afterwards. I propose that we should do a deep dive on this during the CLI epic, pulumi/pulumi-service#2. This resolves pulumi/pulumi-fabric#305.
2017-08-06 19:05:51 +02:00
var showReplacementSteps bool
Introduce an OpSame planning step This change introduces an OpSame planning step. The reason we need this is so that we can apply the necessary output properties, including the ID, even as we are simply walking the plan (i.e., when we aren't actually performing a deployment). This ensures that the object state evolves as required to let reads of output properties propagate in the ways necessary to reproduce past executions of the program.
2017-06-11 17:09:20 +02:00
var showSames bool
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
var summary bool
var cmd = &cobra.Command{
Add some command hints I sometimes revert back to some ancient version of the system, and I figure with so many other tools using different verbs here, it's worth at least improving our help text with the SuggestFors.
2017-10-21 02:36:47 +02:00
Use: "preview",
Add a handful of aliases/suggestions (#557)
2017-11-13 23:59:11 +01:00
Aliases: []string{"pre"},
SuggestFor: []string{"build", "plan"},
Add some command hints I sometimes revert back to some ancient version of the system, and I figure with so many other tools using different verbs here, it's worth at least improving our help text with the SuggestFors.
2017-10-21 02:36:47 +02:00
Short: "Show a preview of updates to an stack's resources",
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
Long: "Show a preview of updates an stack's resources\n" +
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +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
"This command displays a preview of the updates to an existing stack whose state is\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
"represented by an existing snapshot file. The new desired state is computed by compiling\n" +
"and evaluating an executable package, and extracting all resource allocations from its\n" +
"resulting object graph. These allocations are then compared against the existing state to\n" +
"determine what operations must take place to achieve the desired state. No changes to 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 will actually take place.\n" +
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
"\n" +
Support -C/--cwd instead of path to package Previously, you could pass an explicit path to a Pulumi program when running preview or update and the tool would use that program when planning or deploying, but continue to write state in the cwd. While being able to operate on a specific package without having to cd'd all over over the place is nice, this specific implemntation was a little scary because it made it easier to run two different programs with the same local state (e.g config and checkpoints) which would lead to surprising results. Let's move to a model that some tools have where you can pass a working directory and the tool chdir's to that directory before running. This way any local state that is stored will be stored relative to the package we are operating on instead of whatever the current working directory is. Fixes #398
2017-10-06 17:50:54 +02:00
"The package to execute is loaded from the current directory. Use the `-C` or `--cwd` flag to\n" +
"use a different directory.",
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 {
Add Pulumi.com backend, unify cobra Commands As part of the unification it became clear where we did not support features that we had for the local backend. I opened issues and added comments.
2017-11-01 22:55:16 +01:00
stackName, err := explicitOrCurrent(stack, backend)
Encrypt secrets in Pulumi.yaml We now encrypt secrets at rest based on a key derived from a user suplied passphrase. The system is designed in a way such that we should be able to have a different decrypter (either using a local key or some remote service in the Pulumi.com case in the future). Care is taken to ensure that we do not leak decrypted secrets into the "info" section of the checkpoint file (since we currently store the config there). In addtion, secrets are "pay for play", a passphrase is only needed when dealing with a value that's encrypted. If secure config values are not used, `pulumi` will never prompt you for a passphrase. Otherwise, we only prompt if we know we are going to need to decrypt the value. For example, `pulumi config <key>` only prompts if `<key>` is encrypted and `pulumi deploy` and friends only prompt if you are targeting a stack that has secure configuration assoicated with it. Secure values show up as unecrypted config values inside the language hosts and providers.
2017-10-19 00:37:18 +02:00
if err != nil {
return err
}
Define backend interface, move local implementation behind it This change introduces an abstraction for a `backend` which manages the implementation of some CLI commands. As part of defining the interface, we introduce a new local backend implementation that just uses data local to the machine. This will let us share argument parsing and some display information between the local case and the pulumi.com case in the CLI. We can continue to refine this interface over time (e.g. today we have the implementation of the Destroy/Update/Preview actually writing output but instead they should be returning strongly typed data that the CLI knows how to display and is unified across Pulumi.com deploys and local deploys). But this is a good first step.
2017-11-01 21:34:19 +01:00
return backend.Preview(stackName, debug, engine.PreviewOptions{
Prettify the CLI in a few places This changes a few things in the CLI, mostly just prettying it up: * Label all steps more clearly with the kind of step. Also unify the way we present this during planning and deployment. * Summarize the changes that *did not* get made just as clearly as those that did. In other words, stuff like this: info: 2 resources changed: +1 resource created -1 resource deleted 5 resources unchanged and info: no resources required 5 resources unchanged * Always print output properties when they are pertinent. This includes creates, replacements, and updates. * Show replacement creates and deletes very distinctly. The create parts show up minty green and the delete parts show up rosey red. These are the "physical" steps, compared to the "logical" step of replacement (which remains marigold). I still don't love where we are here. The asymmetry between planning and deployment bugs me, and could be surprising. ("Hey, my deploy doesn't look like my plan!") I don't know what developers will want to see here and I feel like in general we are spewing far too much into the CLI to make it even useful for anything but diagnosing failures afterwards. I propose that we should do a deep dive on this during the CLI epic, pulumi/pulumi-service#2. This resolves pulumi/pulumi-fabric#305.
2017-08-06 19:05:51 +02:00
Analyzers: analyzers,
Switch to a --parallel=P flag This change flips the polarity on parallelism: rather than having a --serialize flag, we will have a --parallel=P flag, and by default we will shut off parallelism. We aren't benefiting from it at the moment (until we implement pulumi/pulumi-fabric#106), and there are more hidden dependencies in places like AWS Lambdas and Permissions than I had realized. We may revisit the default, but this allows us to bite off the messiness of dependsOn only when we benefit from it. And in any case, the --parallel=P capability will be useful.
2017-09-17 17:10:46 +02:00
Parallel: parallel,
Prettify the CLI in a few places This changes a few things in the CLI, mostly just prettying it up: * Label all steps more clearly with the kind of step. Also unify the way we present this during planning and deployment. * Summarize the changes that *did not* get made just as clearly as those that did. In other words, stuff like this: info: 2 resources changed: +1 resource created -1 resource deleted 5 resources unchanged and info: no resources required 5 resources unchanged * Always print output properties when they are pertinent. This includes creates, replacements, and updates. * Show replacement creates and deletes very distinctly. The create parts show up minty green and the delete parts show up rosey red. These are the "physical" steps, compared to the "logical" step of replacement (which remains marigold). I still don't love where we are here. The asymmetry between planning and deployment bugs me, and could be surprising. ("Hey, my deploy doesn't look like my plan!") I don't know what developers will want to see here and I feel like in general we are spewing far too much into the CLI to make it even useful for anything but diagnosing failures afterwards. I propose that we should do a deep dive on this during the CLI epic, pulumi/pulumi-service#2. This resolves pulumi/pulumi-fabric#305.
2017-08-06 19:05:51 +02:00
ShowConfig: showConfig,
ShowReplacementSteps: showReplacementSteps,
ShowSames: showSames,
Summary: summary,
Define backend interface, move local implementation behind it This change introduces an abstraction for a `backend` which manages the implementation of some CLI commands. As part of defining the interface, we introduce a new local backend implementation that just uses data local to the machine. This will let us share argument parsing and some display information between the local case and the pulumi.com case in the CLI. We can continue to refine this interface over time (e.g. today we have the implementation of the Destroy/Update/Preview actually writing output but instead they should be returning strongly typed data that the CLI knows how to display and is unified across Pulumi.com deploys and local deploys). But this is a good first step.
2017-11-01 21:34:19 +01:00
})
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
}),
}
cmd.PersistentFlags().StringSliceVar(
&analyzers, "analyzer", []string{},
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
"Run one or more analyzers as part of this preview")
Add a --debug option to plan, deploy, and destroy This change introduces a --debug option to the plan, deploy, and destroy commands. Unlike --logtostderr, which merely hooks into the copious Glogging that we perform (and is therefore meant for developers of the tools themselves and not end users), --debug hooks into the user-facing debug stream. This now includes any debug messages coming from the resource providers as they perform their tasks.
2017-07-14 02:09:46 +02:00
cmd.PersistentFlags().BoolVarP(
&debug, "debug", "d", false,
"Print detailed debugging output during resource operations")
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
cmd.PersistentFlags().StringVarP(
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, "stack", "s", "",
"Choose an stack other than the currently selected one")
Switch to a --parallel=P flag This change flips the polarity on parallelism: rather than having a --serialize flag, we will have a --parallel=P flag, and by default we will shut off parallelism. We aren't benefiting from it at the moment (until we implement pulumi/pulumi-fabric#106), and there are more hidden dependencies in places like AWS Lambdas and Permissions than I had realized. We may revisit the default, but this allows us to bite off the messiness of dependsOn only when we benefit from it. And in any case, the --parallel=P capability will be useful.
2017-09-17 17:10:46 +02:00
cmd.PersistentFlags().IntVarP(
&parallel, "parallel", "p", 0,
"Allow P resource operations to run in parallel at once (<=1 for no parallelism)")
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
cmd.PersistentFlags().BoolVar(
&showConfig, "show-config", false,
"Show configuration keys and variables")
Implement `get` functions on all resources This change implements the `get` function for resources. Per pulumi/lumi#83, this allows Lumi scripts to actually read from the target environment. For example, we can now look up a SecurityGroup from its ARN: let group = aws.ec2.SecurityGroup.get( "arn:aws:ec2:us-west-2:153052954103:security-group:sg-02150d79"); The returned object is a fully functional resource object. So, we can then link it up with an EC2 instance, for example, in the usual ways: let instance = new aws.ec2.Instance(..., { securityGroups: [ group ], }); This didn't require any changes to the RPC or provider model, since we already implement the Get function. There are a few loose ends; two are short term: 1) URNs are not rehydrated. 2) Query is not yet implemented. One is mid-term: 3) We probably want a URN-based lookup function. But we will likely wait until we tackle pulumi/lumi#109 before adding this. And one is long term (and subtle): 4) These amount to I/O and are not repeatable! A change in the target environment may cause a script to generate a different plan intermittently. Most likely we want to apply a different kind of deployment "policy" for such scripts. These are inching towards the scripting model of pulumi/lumi#121, which is an entirely different beast than the repeatable immutable infrastructure deployments. Finally, it is worth noting that with this, we have some of the fundamental underpinnings required to finally tackle "inference" (pulumi/lumi#142).
2017-06-20 02:24:00 +02:00
cmd.PersistentFlags().BoolVar(
Prettify the CLI in a few places This changes a few things in the CLI, mostly just prettying it up: * Label all steps more clearly with the kind of step. Also unify the way we present this during planning and deployment. * Summarize the changes that *did not* get made just as clearly as those that did. In other words, stuff like this: info: 2 resources changed: +1 resource created -1 resource deleted 5 resources unchanged and info: no resources required 5 resources unchanged * Always print output properties when they are pertinent. This includes creates, replacements, and updates. * Show replacement creates and deletes very distinctly. The create parts show up minty green and the delete parts show up rosey red. These are the "physical" steps, compared to the "logical" step of replacement (which remains marigold). I still don't love where we are here. The asymmetry between planning and deployment bugs me, and could be surprising. ("Hey, my deploy doesn't look like my plan!") I don't know what developers will want to see here and I feel like in general we are spewing far too much into the CLI to make it even useful for anything but diagnosing failures afterwards. I propose that we should do a deep dive on this during the CLI epic, pulumi/pulumi-service#2. This resolves pulumi/pulumi-fabric#305.
2017-08-06 19:05:51 +02:00
&showReplacementSteps, "show-replacement-steps", false,
"Show detailed resource replacement creates and deletes instead of a single step")
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
cmd.PersistentFlags().BoolVar(
Introduce an OpSame planning step This change introduces an OpSame planning step. The reason we need this is so that we can apply the necessary output properties, including the ID, even as we are simply walking the plan (i.e., when we aren't actually performing a deployment). This ensures that the object state evolves as required to let reads of output properties propagate in the ways necessary to reproduce past executions of the program.
2017-06-11 17:09:20 +02:00
&showSames, "show-sames", false,
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
"Show resources that needn't be updated because they haven't changed, alongside those that do")
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
cmd.PersistentFlags().BoolVar(
&summary, "summary", false,
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
"Only display summarization of resources and operations")
Add a `plan` command; move `env destroy` to just `destroy` This change adds a `coco plan` command which is simply a shortcut to the more verbose `coco deploy --dry-run`. This will make demos flow nicer and elevates planning, an important activity, to a more prominent position. The `--dry-run` (aka `-n`) flag is still there. This change also renames `coco env destroy` to just `coco destroy`. This is consistent with deploy and plan being at the top-level. We now use `coco env` purely for evironment management commands (init, config, rm, etc).
2017-03-15 23:40:06 +01:00
return cmd
}
Reference in a new issue Copy permalink