Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PULUMI_BACKEND_URL env var #5789

Merged
merged 3 commits into from
Nov 22, 2020
Merged

Add PULUMI_BACKEND_URL env var #5789

merged 3 commits into from
Nov 22, 2020

Conversation

lukehoban
Copy link
Member

The PULUMI_BACKEND_URL env var allows specifying the backend to use instead of deferring to the project or the ~/.pulumi/credentials.json file to decide on the "current" backend. This allows for using Pulumi without a dependence on this piece of global filesystem state, so that each pulumi invocation can control the exact backend it want's to operate on, without having to do stateful pulumi login/pulumi logout operations.

This is especially useful for automation scenarios like Automation API generally (and effectively solves #5591), or pulumi/pulumi-kubernetes-operator#83 specifically.

This also makes things like

pulumi login $PULUMI_BACKEND_URL
less necessary, and possible to accomplish for any containerized pulumi execution without the need for this logic to be embedded in bash scripts wrapping the CLI.

lukehoban added a commit to pulumi/pulumi-kubernetes-operator that referenced this pull request Nov 20, 2020
Adds a top level `backend` field to the Stack CR that allows pointing all operations for the target Stack at the given backend.  In cases where `backend` is set to a non-service backend, the AccessTokenSecret field is also no longer required.

This is dependent on pulumi/pulumi#5789, and cannot be merged until the operator can take a dependency on that change in the core `pulumi` CLI.

Fixes #83.
The PULUMI_BACKEND_URL env var allows specifying the backend to use instead of deferring to the project or the ~/.pulumi/credentials.json file to decide on the "current" backend.  This allows for using Pulumi without a dependence on this piece of global filesystem state, so that each `pulumi` invocation can control the exact backend it want's to operate on, without having to do stateful `pulumi login`/`pulumi logout` operations.

This is especially useful for automation scenarios like Automation API generally (and effectively solves #5591), or pulumi/pulumi-kubernetes-operator#83 specifically.

This also makes things like https://github.com/pulumi/pulumi/blob/efe7a599e65637378b9ceeac125386b5effd0d68/dist/actions/entrypoint.sh#L10 less necessary, and possible to accomplish for any containerized `pulumi` execution without the need for this logic to be embedded in bash scripts wrapping the CLI.
@lukehoban lukehoban merged commit 4ecd8f9 into master Nov 22, 2020
@pulumi-bot pulumi-bot deleted the lukehoban/pulumi_backend branch November 22, 2020 23:28
lukehoban added a commit to pulumi/pulumi-kubernetes-operator that referenced this pull request Dec 3, 2020
Adds a top level `backend` field to the Stack CR that allows pointing all operations for the target Stack at the given backend.  In cases where `backend` is set to a non-service backend, the AccessTokenSecret field is also no longer required.

This is dependent on pulumi/pulumi#5789, and cannot be merged until the operator can take a dependency on that change in the core `pulumi` CLI.

Fixes #83.
lukehoban added a commit to pulumi/pulumi-kubernetes-operator that referenced this pull request Dec 3, 2020
Adds a top level `backend` field to the Stack CR that allows pointing all operations for the target Stack at the given backend.  In cases where `backend` is set to a non-service backend, the AccessTokenSecret field is also no longer required.

This is dependent on pulumi/pulumi#5789, and cannot be merged until the operator can take a dependency on that change in the core `pulumi` CLI.

Fixes #83.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants