Commit graph

156 commits

Author SHA1 Message Date
Justin Van Patten 2dd13292a3
Consolidate some new and up functionality (#1884)
Previously `new` was operating under the assumption that it was always
going to be creating a new project/stack, and would always prompt for
these values. However, we want to be able to use `new` to pull down the
source for an existing stack. This change adds a `--stack` flag to `new`
that can be used to specify an existing stack. If the specified stack
already exists, we won't prompt for the project name/description, and
instead just use the existing stack's values. If `--stack` is specified,
but doesn't already exist, it will just use that as the stack name
(instead of prompting) when creating the stack. `new` also now handles
configuration like `up <url>`: if the stack is a preconfigured empty
stack (i.e. it was created/configured in the Pulumi Console via Pulumi
Button or New Project), we will use the existing stack's config without
prompting. Otherwise we will prompt for config, and just like `up
<url>`, we'll use the existing stack's config values as defaults when
prompting, or if the stack didn't exist, use the defaults from the
template.

Previously `up <url>`'s handling of the project name/description wasn't
correct: it would always automatically use the values from the template
without prompting. Now, just like `new`:

 - When updating an existing stack, it will not prompt, and just use the
   existing stack's values.

 - When creating a new stack, it will prompt for the project
   name/description, using the defaults from the template.

This PR consolidates some of the `new`/`up` implementation so it shares
code for this functionality. There's definitely opportunities for a lot
more code reuse, but that cleanup can happen down the line if/when we
have the cycles.
2018-09-06 12:45:56 -07:00
joeduffy b1f7cf7050 Fix a few lint warnings 2018-09-05 08:25:23 -07:00
joeduffy 95e917441a Implement preview-then-update for local stacks
This change implements the same preview behavior we have for
cloud stacks, in pkg/backend/httpbe, for local stacks, in
pkg/backend/filebe. This mostly required just refactoring bits
and pieces so that we can share more of the code, although it
does still entail quite a bit of redundancy. In particular, the
apply functions for both backends are now so close to being
unified, but still require enough custom logic that it warrants
keeping them separate (for now...)
2018-09-05 07:33:18 -07:00
joeduffy bf51d7594a Refactor display logic out of pkg/backend/filestate
This simply refactors all the display logic out of the
pkg/backend/filestate package. This helps to gear us up to better unify
this logic between the filestate and httpstate backends.

Furthermore, this really ought to be in its own non-backend,
CLI-specific package, but I'm taking one step at a time here.
2018-09-05 07:33:18 -07:00
joeduffy d28f0cb7b6 Alter the login prompt
This change alters the login prompt slightly, so that it is more
obvious that alternative methods exist.

Before this change, we would say:

    $ pulumi login
    We need your Pulumi account to identify you.
    Enter your access token from https://app.pulumi.com/account
        or hit <ENTER> to log in using your browser            :

After this change, we say this instead:

    $ pulumi login
    Manage your Pulumi stacks by logging in.
    Run `pulumi login --help` for alternative login options.
    Enter your access token from https://app.pulumi.com/account
        or hit <ENTER> to log in using your browser            :

Also updated the help text to advertise this a bit more prominently.
2018-09-05 07:32:42 -07:00
joeduffy feaea31f7b Rename backend packages
This renames the backend packages to more closely align with the
new direction for them. Namely, pkg/backend/cloud becomes
pkg/backend/httpstate and pkg/backend/local becomes
pkg/backend/filestate. This also helps to clarify that these are meant
to be around state management and so the upcoming refactoring required
to split out (e.g.) the display logic (amongst other things) will make
more sense, and we'll need better package names for those too.
2018-09-05 07:32:42 -07:00