This commit implements the `pulumi query` as a dedicated command in the
CLI. The semantics of this command are to run a program in "query mode",
which disallows all resource operations, but allows access to stack
snapshots, as well as various query primitives.
By default `query` will run the query program in the currend directory,
but as with `up`, you can us the `--cwd` or `-C` flags to customize
this.
The Pulumi CLI currently has two "display modes" -- one for rendering
diffs and one for rendering program updates. Neither of these is
particularly well-suited to `pulumi query`, which essentially needs to
render stdout from the query program verbatim.
This commit will add a separate display mode for this purpose:
* In interactive mode, `pulumi query` will use the display spinner to
say "running query". In non-interactive mode, this will be omitted.
* Query mode will print stdout from the query program verbatim, but
ignore `diag.Infoerr` so that they're not double-printed when they're
emitted again as error events.
* Query mode also does not double-print newlines at the end of diag
events.
Right now, when we run `npm install` as part of `pulumi new`, the
following warnings are emitted:
```
node-pre-gyp WARN Using needle for node-pre-gyp https download
...
npm WARN aws-typescript@ No description
npm WARN aws-typescript@ No repository field.
npm WARN aws-typescript@ No license field.
```
We can suppress these warnings by specifying `--loglevel=error` to the
`npm install` command.
For users in secure environments without internet access the update
check in pulumi causes a significant hitch on running any pulumi
command, as pulumi tries to access pulumi.com to get the latest version
and after a while times out.
This commit adds an envvar (PULUMI_SKIP_UPDATE_CHECK) that if set to "1"
or "true" will cause pulumi to skip the update check.
This change adds a --json flag to the preview command, enabling
basic JSON serialization of preview plans. This effectively flattens
the engine event stream into a preview structure that contains a list
of steps, diagnostics, and summary information. Each step contains
the deep serialization of resource state, in addition to metadata about
the step, such as what kind of operation it entails.
This is a partial implementation of pulumi/pulumi#2390. In particular,
we only support --json on the `preview` command itself, and not `up`,
meaning that it isn't possible to serialize the result of an actual
deployment yet (thereby limiting what you can do with outputs, etc).
Use `result.Result` in more places, so when a confirmation prompt is
declined, we just return `result.Bail()` after printing a message
without the `error: ` prefix.
Fixes#2070
`pulumi stack rename` allows you to change the name of an existing
stack. This operation is non-distructive, however it is possible that
the next update will show additional changes to resources, if the
pulumi program uses the value of `getStack()` as part of a resource
name.
Originally, `pulumi new` did not run `up` after generating a project. To
help users get a deployed stack as quickly as possible, we changed
`pulumi new` to run an initial deployment at the end of its operation.
Users would first see a preview and get to decide whether to proceed
with an initial deployment, and then continue to iterate from there.
Note that this would only happen for nodejs projects
(TypeScript/JavaScript). We would not run `up` for Python projects as we
require the user to run `pip install` in a virtualenv, so we'd print
instructions with the necessary commands the user must run instead.
Running `up` as part of `pulumi new` for nodejs projects has ended up
being more confusing than helpful for new users, and annoying for
experienced users. New users aren't expecting `pulumi new` to run an
initial deployment after generating the project (they haven't even
looked at the project source yet). Experienced users find it frustrating
as you typically want to just generate the project, and don't want to
have to wait for the preview just to decline running the update.
This change reverts `pulumi new` back to not running `up` automatically
for nodejs projects. Instead, like with Python projects, at the end of
the operation, we print instructions to the user to run `pulumi up` to
deploy the project.
Show `brew upgrade pulumi` as the upgrade message when the currently
running pulumi executable is on macOS and running from the brew install
directory.
When stack names had to be unique across an entire organization, we
had a convention that stack names would be prefixed by the project
name, to prevent collisions.
Now that stack names are scoped within a project, we no longer need to
include the project name in the stack name. So when running `pulumi
new` to scaffhold a new project, just recommend the name `dev` for the
stack to create instead of `<project-name>-dev`.
Fixes#1417
Some changes to `pulumi new` to improve the experience:
- Color the default values for config differently to make them stand
out better
- Mention that `new` will also perform an initial deployment
- Add more vertical whitespace between steps in the process
- Print message indicating the "Installing dependencies" step is
complete
- After "project is ready to go", add a note about doing an initial
deployment
- Output follow-up command to run when an update fails
- Go back to showing the `npm install` output as `npm` doesn't always
return an error code when it runs into problems
We haven't shipped this yet, and it feels like returning a dictionary
where the keys are config keys and the value is an object that tells
you if it is a secret or not (and its value if it is secret and you
have passed `--show-secrets`) is going to be better overall.
This supports using `--json` to get configuration information in a
structured way.
The objects we return have the following schema:
```
{
name: string;
value: string?;
secret: bool;
}
```
In the case of `pulumi config` when --show-secrets is not passed, and
there are secret values, the `value` property of the object for that
configuration value will not be set. This differs from the normal
rendering where we show `[secret]`.
Contributes To #496
- Ensure new projects have a project name in line with what we'd like
to enforce going forward
- Do more aggresive validation during the interactive prompts during
`pulumi new`
- Fix an issue where the interactive prompt rendered weridly when
there was a validation error
Contributes to #1988Fixes#1441
This reverts commit fe6567a9a7.
We've decided to change get.pulumi.com to not require this, so
reverting the change to make the already long command no longer than
needed.
We currently leave behind the template section inside Pulumi.yaml after
`pulumi new`. While we may eventually make use of it, we're not
currently using it, so it's cleaner to just remove it for now.
We upgraded get.pulumi.com to require TLS1.2. Because powershell does
not support this out of the box, we had to augment the install command
to also enable support for TLS1.2. While we did this on pulumi.io in
our documentation, we also print a similar message on Windows when the
CLI is out of date.
This change augments the message to include enabiling TLS 1.2 during
the invocation.
* Initial stack history command
* Adding use of color pkg, adding background colors to color pkg, and removing extra stack output
* gofmt-ed colors file
* Fixing format and removing JSON output
* Fixing nits, changing output for environment, and adding some tests
* fixing failing history test
As of this change, all of the stack specific commands for `pulumi` now
allow passing `--stack` to operate on a different stack from the
default one.
Fixes#1648
Before the windows console will understand ANSI colorization codes the
terminal must be put in a special mode by passing
ENABLE_VIRTUAL_TERMINAL_PROCESSING to SetConsoleMode. This was
happening as a side effect of term.StdStreams() from a docker package,
which we did before displaying the update data. However, any
colorization done before that call would just show the raw ANSI escape
codes.
Call this helper much earlier (i.e. as soon as the CLI starts up) so
any messages that we print will have the correct colorization applied
to them.
Fixes#2214
This option allows the user to override the file used to fetch and store
configuration information for a stack. It is available for the config,
destroy, logs, preview, refresh, and up commands.
Note that this option is not persistent: if it is not specified, the
stack's default configuration will be used. If an alternate config file
is used exclusively for a stack, it must be specified to all commands
that interact with that stack.
This option can be used to share plaintext configuration across multiple
stacks. It cannot be used to share secret configuration, as secrets are
associated with a particular stack and cannot be decryptex by other
stacks.
* Don't attempt to install packages for Python new
Global installation of packages is almost always not what a user will
want when running 'pulumi new'. This commit instead prints out the
commands that a user should run in order to create a new virtualenv and
install the required Pulumi packages within it.
* CR feedback
When an update is in progress, `pulumi stack ls` was showing the LAST
UPDATE time as "a long while ago" because the service API returns 0 as
the last update time.
Handle this case correctly, displaying "in progress" for the update
time. When using JSON output, we don't include the update time (just
like a stack that has never been updated) but we do set the
`updateInProgress` property of the returned object
Fixes#2042
We run the same suite of changes that we did on gometalinter. This
ended up catching a few new issues, some of which were addressed and
some of which were baselined.
`pulumi up <arg>` does not currently support template names like `pulumi
new`; `up` is hard-coded to only support URLs to templates. This
prevents us from displaying shorter `$ pulumi up ...` commands in the
Pulumi Console when the URL is to one of our standard Pulumi templates.
In such cases, we'd like to be able to show the command with just the
template name instead of a full URL to the template in the
pulumi/templates repo.
This changes `up` to support the standard Pulumi template names
just like `new`.
Also, while making changes here, if a URL specified to `up` contains
multiple templates in subdirectories, allow the user to choose the
template, just like with `new`.
Whenever we need to display a template description, if the Pulumi.yaml
doesn't have it, but has a project description, just use the project
description. This will allow us to avoid having the same description for
both the project and template in our examples.
The new command shouldn't show you the "this command will walk you
through" prelude when using the `-g` command -- it's not helpful and
generally looks confusing.
In preparation for some workspace restructuring, I decided to scratch a
few itches of my own in the code:
* Change project's RuntimeInfo field to just Runtime, to match the
serialized name in JSON/YAML.
* Eliminate the no-longer-used Context and NoDefaultIgnores fields on
project, and all of the associated legacy PPC-related code.
* Eliminate the no-longer-used IgnoreFile constant.
* Remove a bunch of "// nolint: lll" annotations, and simply format
the structures with comments on dedicated lines, to avoid overly
lengthy lines and lint suppressions.
* Mark Dependencies and InitErrors as `omitempty` in the JSON
serialization directives for CheckpointV2 files. This was done for
the YAML directives, but (presumably accidentally) omitted for JSON.
When outputing JSON, if we have a fixed number of log entries (i.e. we
are not `--follow`'ing, we wrap each entry in array. Otherwise, we
just emit each log entry as an object at top level.
As part of this change, I've adopted a slightly more precise time
output format in `pulumi stack ls` when using JSON output. These times
now match the default output from `console.log(new Date())`
Downlevel versions of the Pulumi Node SDK assumed that a parallelism
level of zero implied serial execution, which current CLIs use to signal
unbounded parallelism. This commit works around the downlevel issue by
using math.MaxInt32 to signal unbounded parallelism.
