mirror of https://github.com/pulumi/pulumi.git
bd87211ec6
11165: [cli] Experimental support for remote operations r=justinvp a=justinvp This change adds experimental CLI support for remote operations. For the new CLI flags to show up `PULUMI_EXPERIMENTAL` envvar must best to a truthy value. Automation API (separate PRs for each language forthcoming), leverage these commands and flags under the covers. Here's an example: ``` PULUMI_EXPERIMENTAL=true pulumi up --remote https://github.com/pulumi/examples.git \ --stack="justinvp/aws-ts-s3-folder/dev" \ --remote-git-branch="refs/heads/master" \ --remote-git-repo-dir="aws-ts-s3-folder" \ --remote-env="AWS_REGION=us-west-2" \ --remote-env="AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID" \ --remote-env-secret="AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY" \ --remote-env-secret="AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN" ``` And similar for `preview`, `refresh`, and `destroy` commands. Note: While this will initially be behind `PULUMI_EXPERIMENTAL`, I expect we will make these flags available by default for regular CLI use at some point. In addition to the code review, I'm looking for feedback on the following: 1. This leverages `pulumi up`'s existing `pulumi up [url]` URL argument (and adds a similar URL argument to the other commands). When `--remote` is specified, the URL arg means the git repo URL to pass to the deployment API. I was debating whether `--remote-git-branch` and `--remote-git-commit` (one of those must be set; mutually exclusive) should be a second arg like `pulumi up [url] [ref]`, and additionally if `--remote-git-repo-dir` should be a third arg like `pulumi up [url] [ref] [dir]`. I decided to go with flags because it's possible we'll make branch/commit optional in the future, which would make it awkward if you have to pass a repo-dir as a third arg (requiring specifying a branch/commit second arg). Also, having branch/commit as a single arg would mean we'd have to try to determine whether it looks like a commit hash vs. a branch. Open to feedback here. 2. ~~The deployment API supports secrets for envvar values. I may have gone too cute with how these are specified via the CLI. Regular values are specified with `NAME=value` (`=` separator). Secret values are specified like `NAME#=secretvalue` (`#=` separator). Alternatively, I could have separate flags like `--remote-env` and `--remote-env-secret` which is probably more straightforward. Feedback appreciated.~~ **Update:** Added a separate `--remote-env-secret` flag for envvar secrets. Note: I do plan to include some sanity tests, but need to make sure whatever account we use when `PULUMI_ACCESS_TOKEN` is set has the feature enabled in the service. Will do that as a follow-up. Co-authored-by: Justin Van Patten <jvp@justinvp.com> |
||
|---|---|---|
| .. | ||
| authhelpers | ||
| backend | ||
| cmd/pulumi | ||
| codegen | ||
| engine | ||
| graph | ||
| operations | ||
| resource | ||
| secrets | ||
| testing/integration | ||
| util | ||
| version | ||
| README.md | ||
| go.mod | ||
| go.sum | ||
README.md
pulumi/pkg
While pulumi/sdk maintains strict backwards compatibility guarantees, code under pkg/ is handled more informally: while breaking changes are still discouraged they may happen when they make sense.