History

bors[bot] bd87211ec6 Merge #11165 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>		2022-10-28 01:05:54 +00:00
..
auto	[auto] detect concurrent update error from local backend	2022-10-26 17:02:47 +02:00
common	Merge #11165	2022-10-28 01:05:54 +00:00
pulumi	Inherit the providers map between components	2022-10-20 15:35:50 -07:00
pulumi-language-go	chore: Update doc comments, coding style, fix lint	2022-10-13 13:50:49 -07:00
Makefile	ci: Enable testing of language version sets	2022-09-21 09:48:38 -07:00
README.md	`pulumi update` => `pulumi up` (#2702 )	2019-05-06 14:00:18 -07:00

README.md

Pulumi Golang SDK

This directory contains support for writing Pulumi programs in the Go language. There are two aspects to this:

pulumi/ contains the client language bindings Pulumi program's code directly against;
pulumi-language-go/ contains the language host plugin that the Pulumi engine uses to orchestrate updates.

To author a Pulumi program in Go, simply say so in your Pulumi.yaml

name: <my-project>
runtime: go

and ensure you have pulumi-language-go on your path (it is distributed in the Pulumi download automatically).

By default, the language plugin will use your project's name, <my-project>, as the executable that it loads. This too must be on your path for the language provider to load it when you run pulumi preview or pulumi up.