Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
// Copyright 2016-2023, Pulumi Corporation.
|
2018-05-22 19:43:36 +00:00
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
|
|
|
|
package backend
|
|
|
|
|
|
|
|
import (
|
2018-05-08 01:23:03 +00:00
|
|
|
"context"
|
2021-11-13 02:37:17 +00:00
|
|
|
"errors"
|
2018-04-17 23:37:52 +00:00
|
|
|
"fmt"
|
2019-11-07 16:22:59 +00:00
|
|
|
"strings"
|
2018-09-14 03:54:42 +00:00
|
|
|
"time"
|
2018-04-17 23:37:52 +00:00
|
|
|
|
2023-10-10 01:35:39 +00:00
|
|
|
"github.com/pulumi/esc"
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/pkg/v3/backend/display"
|
2023-09-18 11:01:28 +00:00
|
|
|
sdkDisplay "github.com/pulumi/pulumi/pkg/v3/display"
|
2021-03-17 13:20:05 +00:00
|
|
|
"github.com/pulumi/pulumi/pkg/v3/engine"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/operations"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/resource/deploy"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/resource/stack"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/secrets"
|
|
|
|
"github.com/pulumi/pulumi/pkg/v3/util/cancel"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/apitype"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/diag"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/config"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/result"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/workspace"
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
)
|
|
|
|
|
2023-03-03 16:36:39 +00:00
|
|
|
// ErrNoPreviousDeployment is returned when there isn't a previous deployment.
|
|
|
|
var ErrNoPreviousDeployment = errors.New("no previous deployment")
|
Initial support for passing URLs to `new` and `up` (#1727)
* Initial support for passing URLs to `new` and `up`
This PR adds initial support for `pulumi new` using Git under the covers
to manage Pulumi templates, providing the same experience as before.
You can now also optionally pass a URL to a Git repository, e.g.
`pulumi new [<url>]`, including subdirectories within the repository,
and arbitrary branches, tags, or commits.
The following commands result in the same behavior from the user's
perspective:
- `pulumi new javascript`
- `pulumi new https://github.com/pulumi/templates/templates/javascript`
- `pulumi new https://github.com/pulumi/templates/tree/master/templates/javascript`
- `pulumi new https://github.com/pulumi/templates/tree/HEAD/templates/javascript`
To specify an arbitrary branch, tag, or commit:
- `pulumi new https://github.com/pulumi/templates/tree/<branch>/templates/javascript`
- `pulumi new https://github.com/pulumi/templates/tree/<tag>/templates/javascript`
- `pulumi new https://github.com/pulumi/templates/tree/<commit>/templates/javascript`
Branches and tags can include '/' separators, and `pulumi` will still
find the right subdirectory.
URLs to Gists are also supported, e.g.:
`pulumi new https://gist.github.com/justinvp/6673959ceb9d2ac5a14c6d536cb871a6`
If the specified subdirectory in the repository does not contain a
`Pulumi.yaml`, it will look for subdirectories within containing
`Pulumi.yaml` files, and prompt the user to choose a template, along the
lines of how `pulumi new` behaves when no template is specified.
The following commands result in the CLI prompting to choose a template:
- `pulumi new`
- `pulumi new https://github.com/pulumi/templates/templates`
- `pulumi new https://github.com/pulumi/templates/tree/master/templates`
- `pulumi new https://github.com/pulumi/templates/tree/HEAD/templates`
Of course, arbitrary branches, tags, or commits can be specified as well:
- `pulumi new https://github.com/pulumi/templates/tree/<branch>/templates`
- `pulumi new https://github.com/pulumi/templates/tree/<tag>/templates`
- `pulumi new https://github.com/pulumi/templates/tree/<commit>/templates`
This PR also includes initial support for passing URLs to `pulumi up`,
providing a streamlined way to deploy installable cloud applications
with Pulumi, without having to manage source code locally before doing
a deployment.
For example, `pulumi up https://github.com/justinvp/aws` can be used to
deploy a sample AWS app. The stack can be updated with different
versions, e.g.
`pulumi up https://github.com/justinvp/aws/tree/v2 -s <stack-to-update>`
Config values can optionally be passed via command line flags, e.g.
`pulumi up https://github.com/justinvp/aws -c aws:region=us-west-2 -c foo:bar=blah`
Gists can also be used, e.g.
`pulumi up https://gist.github.com/justinvp/62fde0463f243fcb49f5a7222e51bc76`
* Fix panic when hitting ^C from "choose template" prompt
* Add description to templates
When running `pulumi new` without specifying a template, include the template description along with the name in the "choose template" display.
```
$ pulumi new
Please choose a template:
aws-go A minimal AWS Go program
aws-javascript A minimal AWS JavaScript program
aws-python A minimal AWS Python program
aws-typescript A minimal AWS TypeScript program
> go A minimal Go program
hello-aws-javascript A simple AWS serverless JavaScript program
javascript A minimal JavaScript program
python A minimal Python program
typescript A minimal TypeScript program
```
* React to changes to the pulumi/templates repo.
We restructured the `pulumi/templates` repo to have all the templates in the root instead of in a `templates` subdirectory, so make the change here to no longer look for templates in `templates`.
This also fixes an issue around using `Depth: 1` that I found while testing this. When a named template is used, we attempt to clone or pull from the `pulumi/templates` repo to `~/.pulumi/templates`. Having it go in this well-known directory allows us to maintain previous behavior around allowing offline use of templates. If we use `Depth: 1` for the initial clone, it will fail when attempting to pull when there are updates to the remote repository. Unfortunately, there's no built-in `--unshallow` support in `go-git` and setting a larger `Depth` doesn't appear to help. There may be a workaround, but for now, if we're cloning the pulumi templates directory to `~/.pulumi/templates`, we won't use `Depth: 1`. For template URLs, we will continue to use `Depth: 1` as we clone those to a temp directory (which gets deleted) that we'll never try to update.
* List available templates in help text
* Address PR Feedback
* Don't show "Installing dependencies" message for `up`
* Fix secrets handling
When prompting for config, if the existing stack value is a secret, keep it a secret and mask the prompt. If the template says it should be secret, make it a secret.
* Fix ${PROJECT} and ${DESCRIPTION} handling for `up`
Templates used with `up` should already have a filled-in project name and description, but if it's a `new`-style template, that has `${PROJECT}` and/or `${DESCRIPTION}`, be helpful and just replace these with better values.
* Fix stack handling
Add a bool `setCurrent` param to `requireStack` to control whether the current stack should be saved in workspace settings. For the `up <url>` case, we don't want to save. Also, split the `up` code into two separate functions: one for the `up <url>` case and another for the normal `up` case where you have workspace in your current directory. While we may be able to combine them back into a single function, right now it's a bit cleaner being separate, even with some small amount of duplication.
* Fix panic due to nil crypter
Lazily get the crypter only if needed inside `promptForConfig`.
* Embellish comment
* Harden isPreconfiguredEmptyStack check
Fix the code to check to make sure the URL specified on the command line matches the URL stored in the `pulumi:template` config value, and that the rest of the config from the stack satisfies the config requirements of the template.
2018-08-11 01:08:16 +00:00
|
|
|
|
2018-05-07 22:31:27 +00:00
|
|
|
// StackAlreadyExistsError is returned from CreateStack when the stack already exists in the backend.
|
|
|
|
type StackAlreadyExistsError struct {
|
|
|
|
StackName string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (e StackAlreadyExistsError) Error() string {
|
|
|
|
return fmt.Sprintf("stack '%v' already exists", e.StackName)
|
|
|
|
}
|
|
|
|
|
2019-11-07 16:22:59 +00:00
|
|
|
// OverStackLimitError is returned from CreateStack when the organization is billed per-stack and
|
|
|
|
// is over its stack limit.
|
|
|
|
type OverStackLimitError struct {
|
|
|
|
Message string
|
|
|
|
}
|
|
|
|
|
|
|
|
func (e OverStackLimitError) Error() string {
|
|
|
|
m := e.Message
|
2023-02-23 20:51:11 +00:00
|
|
|
m = strings.ReplaceAll(m, "Conflict: ", "over stack limit: ")
|
2019-11-07 16:22:59 +00:00
|
|
|
return m
|
|
|
|
}
|
|
|
|
|
2018-04-18 18:25:16 +00:00
|
|
|
// StackReference is an opaque type that refers to a stack managed by a backend. The CLI uses the ParseStackReference
|
|
|
|
// method to turn a string like "my-great-stack" or "pulumi/my-great-stack" into a stack reference that can be used to
|
|
|
|
// interact with the stack via the backend. Stack references are specific to a given backend and different back ends
|
2019-12-30 18:24:48 +00:00
|
|
|
// may interpret the string passed to ParseStackReference differently.
|
2018-04-17 23:37:52 +00:00
|
|
|
type StackReference interface {
|
2018-04-18 18:25:16 +00:00
|
|
|
// fmt.Stringer's String() method returns a string of the stack identity, suitable for display in the CLI
|
2018-04-17 23:37:52 +00:00
|
|
|
fmt.Stringer
|
2018-09-05 14:20:25 +00:00
|
|
|
// Name is the name that will be passed to the Pulumi engine when preforming operations on this stack. This
|
2018-04-18 18:25:16 +00:00
|
|
|
// name may not uniquely identify the stack (e.g. the cloud backend embeds owner information in the StackReference
|
2019-09-26 19:27:37 +00:00
|
|
|
// but that information is not part of the StackName() we pass to the engine.
|
Add tokens.StackName (#14487)
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new type `tokens.StackName` which is a relatively strongly
typed container for a stack name. The only weakly typed aspect of it is
Go will always allow the "zero" value to be created for a struct, which
for a stack name is the empty string which is invalid. To prevent
introducing unexpected empty strings when working with stack names the
`String()` method will panic for zero initialized stack names.
Apart from the zero value, all other instances of `StackName` are via
`ParseStackName` which returns a descriptive error if the string is not
valid.
This PR only updates "pkg/" to use this type. There are a number of
places in "sdk/" which could do with this type as well, but there's no
harm in doing a staggered roll out, and some parts of "sdk/" are user
facing and will probably have to stay on the current `tokens.Name` and
`tokens.QName` types.
There are two places in the system where we panic on invalid stack
names, both in the http backend. This _should_ be fine as we've had long
standing validation that stacks created in the service are valid stack
names.
Just in case people have managed to introduce invalid stack names, there
is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn
off the validation _and_ panicing for stack names. Users can use that to
temporarily disable the validation and continue working, but it should
only be seen as a temporary measure. If they have invalid names they
should rename them, or if they think they should be valid raise an issue
with us to change the validation code.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 07:44:54 +00:00
|
|
|
Name() tokens.StackName
|
2022-11-17 00:14:50 +00:00
|
|
|
|
2023-04-27 08:13:08 +00:00
|
|
|
// Project is the project name that this stack belongs to.
|
2024-01-30 15:53:10 +00:00
|
|
|
// For old diy backends this will return false.
|
2023-04-27 08:13:08 +00:00
|
|
|
Project() (tokens.Name, bool)
|
|
|
|
|
2023-02-10 12:24:28 +00:00
|
|
|
// Fully qualified name of the stack, including any organization, project, or other information.
|
2022-11-29 22:07:03 +00:00
|
|
|
FullyQualifiedName() tokens.QName
|
2018-04-17 23:37:52 +00:00
|
|
|
}
|
|
|
|
|
2019-09-26 19:27:37 +00:00
|
|
|
// PolicyPackReference is an opaque type that refers to a PolicyPack managed by a backend. The CLI
|
2019-06-24 04:39:22 +00:00
|
|
|
// uses the ParsePolicyPackReference method to turn a string like "myOrg/mySecurityRules" into a
|
|
|
|
// PolicyPackReference that can be used to interact with the PolicyPack via the backend.
|
|
|
|
// PolicyPackReferences are specific to a given backend and different back ends may interpret the
|
|
|
|
// string passed to ParsePolicyPackReference differently.
|
|
|
|
type PolicyPackReference interface {
|
|
|
|
// fmt.Stringer's String() method returns a string of the stack identity, suitable for display in the CLI
|
|
|
|
fmt.Stringer
|
|
|
|
// OrgName is the name of the organization that is managing the PolicyPack.
|
|
|
|
OrgName() string
|
|
|
|
// Name is the name of the PolicyPack being referenced.
|
|
|
|
Name() tokens.QName
|
|
|
|
}
|
|
|
|
|
2018-09-14 03:54:42 +00:00
|
|
|
// StackSummary provides a basic description of a stack, without the ability to inspect its resources or make changes.
|
|
|
|
type StackSummary interface {
|
|
|
|
Name() StackReference
|
|
|
|
|
|
|
|
// LastUpdate returns when the stack was last updated, as applicable.
|
|
|
|
LastUpdate() *time.Time
|
|
|
|
// ResourceCount returns the stack's resource count, as applicable.
|
|
|
|
ResourceCount() *int
|
|
|
|
}
|
|
|
|
|
2019-08-22 20:56:43 +00:00
|
|
|
// ListStacksFilter describes optional filters when listing stacks.
|
|
|
|
type ListStacksFilter struct {
|
|
|
|
Organization *string
|
|
|
|
Project *string
|
|
|
|
TagName *string
|
|
|
|
TagValue *string
|
|
|
|
}
|
|
|
|
|
2021-07-29 20:37:17 +00:00
|
|
|
// ContinuationToken is an opaque string used for paginated backend requests. If non-nil, means
|
|
|
|
// there are more results to be returned and the continuation token should be passed into a
|
|
|
|
// subsequent call to the backend method. A nil continuation token means all results have been
|
|
|
|
// returned.
|
|
|
|
type ContinuationToken *string
|
|
|
|
|
2021-01-11 18:07:59 +00:00
|
|
|
// Backend is the contract between the Pulumi engine and pluggable backend implementations of the Pulumi Cloud Service.
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
type Backend interface {
|
|
|
|
// Name returns a friendly name for this backend.
|
|
|
|
Name() string
|
2018-09-04 17:44:25 +00:00
|
|
|
// URL returns a URL at which information about this backend may be seen.
|
|
|
|
URL() string
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
|
2023-03-03 20:32:42 +00:00
|
|
|
// SetCurrentProject sets the current ambient project for this backend.
|
|
|
|
SetCurrentProject(proj *workspace.Project)
|
|
|
|
|
2019-06-24 04:39:22 +00:00
|
|
|
// GetPolicyPack returns a PolicyPack object tied to this backend, or nil if it cannot be found.
|
|
|
|
GetPolicyPack(ctx context.Context, policyPack string, d diag.Sink) (PolicyPack, error)
|
|
|
|
|
2020-01-16 20:04:51 +00:00
|
|
|
// ListPolicyGroups returns all Policy Groups for an organization in this backend or an error if it cannot be found.
|
2021-07-29 20:37:17 +00:00
|
|
|
ListPolicyGroups(ctx context.Context, orgName string, inContToken ContinuationToken) (
|
|
|
|
apitype.ListPolicyGroupsResponse, ContinuationToken, error)
|
2020-01-16 20:04:51 +00:00
|
|
|
|
|
|
|
// ListPolicyPacks returns all Policy Packs for an organization in this backend, or an error if it cannot be found.
|
2021-07-29 20:37:17 +00:00
|
|
|
ListPolicyPacks(ctx context.Context, orgName string, inContToken ContinuationToken) (
|
|
|
|
apitype.ListPolicyPacksResponse, ContinuationToken, error)
|
2020-01-16 20:04:51 +00:00
|
|
|
|
2022-03-23 22:05:26 +00:00
|
|
|
// SupportsTags tells whether a stack can have associated tags stored with it in this backend.
|
|
|
|
SupportsTags() bool
|
2023-03-17 19:39:45 +00:00
|
|
|
|
2019-08-12 10:49:22 +00:00
|
|
|
// SupportsOrganizations tells whether a user can belong to multiple organizations in this backend.
|
|
|
|
SupportsOrganizations() bool
|
2022-03-23 22:05:26 +00:00
|
|
|
|
2023-10-27 07:33:07 +00:00
|
|
|
// SupportsProgress tells whether the backend supports showing whether an operation is currently in progress
|
|
|
|
SupportsProgress() bool
|
|
|
|
|
2018-04-17 23:37:52 +00:00
|
|
|
// ParseStackReference takes a string representation and parses it to a reference which may be used for other
|
|
|
|
// methods in this backend.
|
2018-04-20 06:16:07 +00:00
|
|
|
ParseStackReference(s string) (StackReference, error)
|
2019-12-30 18:24:48 +00:00
|
|
|
// ValidateStackName verifies that the string is a legal identifier for a (potentially qualified) stack.
|
|
|
|
// Will check for any backend-specific naming restrictions.
|
|
|
|
ValidateStackName(s string) error
|
2018-04-17 23:37:52 +00:00
|
|
|
|
2019-08-12 09:12:17 +00:00
|
|
|
// DoesProjectExist returns true if a project with the given name exists in this backend, or false otherwise.
|
2023-06-21 15:46:54 +00:00
|
|
|
DoesProjectExist(ctx context.Context, orgName string, projectName string) (bool, error)
|
2019-08-12 09:12:17 +00:00
|
|
|
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// GetStack returns a stack object tied to this backend with the given name, or nil if it cannot be found.
|
2018-05-08 01:23:03 +00:00
|
|
|
GetStack(ctx context.Context, stackRef StackReference) (Stack, error)
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// CreateStack creates a new stack with the given name and options that are specific to the backend provider.
|
2023-03-20 21:12:17 +00:00
|
|
|
CreateStack(ctx context.Context, stackRef StackReference, root string, opts *CreateStackOptions) (Stack, error)
|
2023-02-17 16:05:11 +00:00
|
|
|
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// RemoveStack removes a stack with the given name. If force is true, the stack will be removed even if it
|
|
|
|
// still contains resources. Otherwise, if the stack contains resources, a non-nil error is returned, and the
|
|
|
|
// first boolean return value will be set to true.
|
2019-10-14 21:30:42 +00:00
|
|
|
RemoveStack(ctx context.Context, stack Stack, force bool) (bool, error)
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// ListStacks returns a list of stack summaries for all known stacks in the target backend.
|
2021-07-29 20:37:17 +00:00
|
|
|
ListStacks(ctx context.Context, filter ListStacksFilter, inContToken ContinuationToken) (
|
|
|
|
[]StackSummary, ContinuationToken, error)
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
|
Correctly rename stack files during a rename (#5812)
* Correctly rename stack files during a rename
This fixes pulumi/pulumi#4463, by renaming a stack's configuration
file based on its stack-part, and ignoring the owner-part. Our
workspace system doesn't recognize configuration files with fully
qualified names. That, by the way, causes problems if we have
multiple stacks in different organizations that share a stack-part.
The fix here is simple: propagate the new StackReference from the
Rename operation and rely on the backend's normalization to a
simple name, and then use that the same way we are using a
StackReference to determine the path for the origin stack.
An alternative fix is to recognize fully qualified config files,
however, there's a fair bit of cleanup we will be doing as part of
https://github.com/pulumi/pulumi/issues/2522 and
https://github.com/pulumi/pulumi/issues/4605, so figured it is best
to make this work the way the system expects first, and revisit it
as part of those overall workstreams. I also suspect we may want to
consider changing the default behavior here as part of
https://github.com/pulumi/pulumi/issues/5731.
Tests TBD; need some advice on how best to test this since it
only happens with our HTTP state backend -- all integration tests
appear to use the local filestate backend at the moment.
* Add a changelog entry for bug fix
* Add some stack rename tests
* Fix a typo
* Address CR feedback
* Make some logic clearer
Use "parsedName" instead of "qn", add a comment explaining why
we're doing this, and also explicitly ignore the error rather
than implicitly doing so with _.
2020-12-02 00:55:48 +00:00
|
|
|
// RenameStack renames the given stack to a new name, and then returns an updated stack reference that
|
|
|
|
// can be used to refer to the newly renamed stack.
|
|
|
|
RenameStack(ctx context.Context, stack Stack, newName tokens.QName) (StackReference, error)
|
2019-03-14 22:32:10 +00:00
|
|
|
|
2018-05-05 18:57:09 +00:00
|
|
|
// Preview shows what would be updated given the current workspace's contents.
|
2023-12-05 08:32:40 +00:00
|
|
|
Preview(
|
|
|
|
ctx context.Context, stack Stack, op UpdateOperation, events chan<- engine.Event,
|
|
|
|
) (*deploy.Plan, sdkDisplay.ResourceChanges, result.Result)
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// Update updates the target stack with the current workspace's contents (config and code).
|
2022-06-27 14:08:06 +00:00
|
|
|
Update(ctx context.Context, stack Stack, op UpdateOperation) (sdkDisplay.ResourceChanges, result.Result)
|
2020-10-14 11:51:53 +00:00
|
|
|
// Import imports resources into a stack.
|
|
|
|
Import(ctx context.Context, stack Stack, op UpdateOperation,
|
2022-06-27 14:08:06 +00:00
|
|
|
imports []deploy.Import) (sdkDisplay.ResourceChanges, result.Result)
|
Implement a refresh command
This change implements a `pulumi refresh` command. It operates a bit
like `pulumi update`, and friends, in that it supports `--preview` and
`--diff`, along with the usual flags, and will update your checkpoint.
It works through substitution of the deploy.Source abstraction, which
generates a sequence of resource registration events. This new
deploy.RefreshSource takes in a prior checkpoint and will walk it,
refreshing the state via the associated resource providers by invoking
Read for each resource encountered, and merging the resulting state with
the prior checkpoint, to yield a new resource.Goal state. This state is
then fed through the engine in the usual ways with a few minor caveats:
namely, although the engine must generate steps for the logical
operations (permitting us to get nice summaries, progress, and diffs),
it mustn't actually carry them out because the state being imported
already reflects reality (a deleted resource has *already* been deleted,
so of course the engine need not perform the deletion). The diffing
logic also needs to know how to treat the case of refresh slightly
differently, because we are going to be diffing outputs and not inputs.
Note that support for managed stacks is not yet complete, since that
requires updates to the service to support a refresh endpoint. That
will be coming soon ...
2018-04-10 18:22:39 +00:00
|
|
|
// Refresh refreshes the stack's state from the cloud provider.
|
2022-06-27 14:08:06 +00:00
|
|
|
Refresh(ctx context.Context, stack Stack, op UpdateOperation) (sdkDisplay.ResourceChanges, result.Result)
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// Destroy destroys all of this stack's resources.
|
2022-06-27 14:08:06 +00:00
|
|
|
Destroy(ctx context.Context, stack Stack, op UpdateOperation) (sdkDisplay.ResourceChanges, result.Result)
|
2019-11-06 20:56:29 +00:00
|
|
|
// Watch watches the project's working directory for changes and automatically updates the active stack.
|
2021-06-21 07:34:21 +00:00
|
|
|
Watch(ctx context.Context, stack Stack, op UpdateOperation, paths []string) result.Result
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
|
2019-04-30 18:48:41 +00:00
|
|
|
// Query against the resource outputs in a stack's state checkpoint.
|
2023-09-20 15:43:46 +00:00
|
|
|
Query(ctx context.Context, op QueryOperation) error
|
2019-04-30 18:48:41 +00:00
|
|
|
|
2018-01-25 02:22:41 +00:00
|
|
|
// GetHistory returns all updates for the stack. The returned UpdateInfo slice will be in
|
2018-02-28 22:35:13 +00:00
|
|
|
// descending order (newest first).
|
2021-02-10 00:20:01 +00:00
|
|
|
GetHistory(ctx context.Context, stackRef StackReference, pageSize int, page int) ([]UpdateInfo, error)
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
// GetLogs fetches a list of log entries for the given stack, with optional filtering/querying.
|
2023-01-11 16:04:14 +00:00
|
|
|
GetLogs(ctx context.Context, secretsProvider secrets.Provider, stack Stack, cfg StackConfiguration,
|
2019-04-18 22:57:54 +00:00
|
|
|
query operations.LogQuery) ([]operations.LogEntry, error)
|
2018-04-26 23:13:52 +00:00
|
|
|
// Get the configuration from the most recent deployment of the stack.
|
2019-10-14 21:30:42 +00:00
|
|
|
GetLatestConfiguration(ctx context.Context, stack Stack) (config.Map, error)
|
2018-01-05 20:46:13 +00:00
|
|
|
|
2019-01-04 21:23:47 +00:00
|
|
|
// UpdateStackTags updates the stacks's tags, replacing all existing tags.
|
2019-10-14 21:30:42 +00:00
|
|
|
UpdateStackTags(ctx context.Context, stack Stack, tags map[apitype.StackTagName]string) error
|
2019-01-04 21:23:47 +00:00
|
|
|
|
2018-01-05 20:46:13 +00:00
|
|
|
// ExportDeployment exports the deployment for the given stack as an opaque JSON message.
|
2019-10-14 21:30:42 +00:00
|
|
|
ExportDeployment(ctx context.Context, stack Stack) (*apitype.UntypedDeployment, error)
|
2018-01-05 20:46:13 +00:00
|
|
|
// ImportDeployment imports the given deployment into the indicated stack.
|
2019-10-14 21:30:42 +00:00
|
|
|
ImportDeployment(ctx context.Context, stack Stack, deployment *apitype.UntypedDeployment) error
|
2022-03-31 08:11:19 +00:00
|
|
|
// Returns the identity of the current user and any organizations they are in for the backend.
|
2023-09-23 12:46:11 +00:00
|
|
|
CurrentUser() (string, []string, *workspace.TokenInformation, error)
|
2022-03-03 17:07:05 +00:00
|
|
|
|
|
|
|
// Cancel the current update for the given stack.
|
|
|
|
CancelCurrentUpdate(ctx context.Context, stackRef StackReference) error
|
Improve the overall cloud CLI experience
This improves the overall cloud CLI experience workflow.
Now whether a stack is local or cloud is inherent to the stack
itself. If you interact with a cloud stack, we transparently talk
to the cloud; if you interact with a local stack, we just do the
right thing, and perform all operations locally. Aside from sometimes
seeing a cloud emoji pop-up ☁️, the experience is quite similar.
For example, to initialize a new cloud stack, simply:
$ pulumi login
Logging into Pulumi Cloud: https://pulumi.com/
Enter Pulumi access token: <enter your token>
$ pulumi stack init my-cloud-stack
Note that you may log into a specific cloud if you'd like. For
now, this is just for our own testing purposes, but someday when we
support custom clouds (e.g., Enterprise), you can just say:
$ pulumi login --cloud-url https://corp.acme.my-ppc.net:9873
The cloud is now the default. If you instead prefer a "fire and
forget" style of stack, you can skip the login and pass `--local`:
$ pulumi stack init my-faf-stack --local
If you are logged in and run `pulumi`, we tell you as much:
$ pulumi
Usage:
pulumi [command]
// as before...
Currently logged into the Pulumi Cloud ☁️
https://pulumi.com/
And if you list your stacks, we tell you which one is local or not:
$ pulumi stack ls
NAME LAST UPDATE RESOURCE COUNT CLOUD URL
my-cloud-stack 2017-12-01 ... 3 https://pulumi.com/
my-faf-stack n/a 0 n/a
And `pulumi stack` by itself prints information like your cloud org,
PPC name, and so on, in addition to the usuals.
I shall write up more details and make sure to document these changes.
This change also fairly significantly refactors the layout of cloud
versus local logic, so that the cmd/ package is resonsible for CLI
things, and the new pkg/backend/ package is responsible for the
backends. The following is the overall resulting package architecture:
* The backend.Backend interface can be implemented to substitute
a new backend. This has operations to get and list stacks,
perform updates, and so on.
* The backend.Stack struct is a wrapper around a stack that has
or is being manipulated by a Backend. It resembles our existing
Stack notions in the engine, but carries additional metadata
about its source. Notably, it offers functions that allow
operations like updating and deleting on the Backend from which
it came.
* There is very little else in the pkg/backend/ package.
* A new package, pkg/backend/local/, encapsulates all local state
management for "fire and forget" scenarios. It simply implements
the above logic and contains anything specific to the local
experience.
* A peer package, pkg/backend/cloud/, encapsulates all logic
required for the cloud experience. This includes its subpackage
apitype/ which contains JSON schema descriptions required for
REST calls against the cloud backend. It also contains handy
functions to list which clouds we have authenticated with.
* A subpackage here, pkg/backend/state/, is not a provider at all.
Instead, it contains all of the state management functions that
are currently shared between local and cloud backends. This
includes configuration logic -- including encryption -- as well
as logic pertaining to which stacks are known to the workspace.
This addresses pulumi/pulumi#629 and pulumi/pulumi#494.
2017-12-02 15:29:46 +00:00
|
|
|
}
|
2018-04-20 01:59:14 +00:00
|
|
|
|
2023-10-10 01:35:39 +00:00
|
|
|
// EnvironmentsBackend is an interface that defines an optional capability for a backend to work with environments.
|
|
|
|
type EnvironmentsBackend interface {
|
2023-11-22 20:57:02 +00:00
|
|
|
CreateEnvironment(
|
|
|
|
ctx context.Context,
|
|
|
|
org string,
|
|
|
|
name string,
|
|
|
|
yaml []byte,
|
|
|
|
) (apitype.EnvironmentDiagnostics, error)
|
|
|
|
|
2023-11-21 10:44:45 +00:00
|
|
|
CheckYAMLEnvironment(
|
|
|
|
ctx context.Context,
|
|
|
|
org string,
|
|
|
|
yaml []byte,
|
|
|
|
) (*esc.Environment, apitype.EnvironmentDiagnostics, error)
|
|
|
|
|
2023-10-10 01:35:39 +00:00
|
|
|
// OpenYAMLEnvironment opens a literal environment.
|
|
|
|
OpenYAMLEnvironment(
|
|
|
|
ctx context.Context,
|
|
|
|
org string,
|
|
|
|
yaml []byte,
|
|
|
|
duration time.Duration,
|
2023-11-21 10:44:45 +00:00
|
|
|
) (*esc.Environment, apitype.EnvironmentDiagnostics, error)
|
2023-10-10 01:35:39 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 20:25:57 +00:00
|
|
|
// SpecificDeploymentExporter is an interface defining an additional capability of a Backend, specifically the
|
|
|
|
// ability to export a specific versions of a stack's deployment. This isn't a requirement for all backends and
|
|
|
|
// should be checked for dynamically.
|
|
|
|
type SpecificDeploymentExporter interface {
|
|
|
|
// ExportDeploymentForVersion exports a specific deployment from the history of a stack. The meaning of
|
|
|
|
// version is backend-specific. For the Pulumi Console, it is the numeric version. (The first update
|
|
|
|
// being version "1", the second "2", and so on.) Though this might change in the future to use some
|
|
|
|
// other type of identifier or commitish .
|
|
|
|
ExportDeploymentForVersion(ctx context.Context, stack Stack, version string) (*apitype.UntypedDeployment, error)
|
|
|
|
}
|
|
|
|
|
2020-10-14 11:51:53 +00:00
|
|
|
// UpdateOperation is a complete stack update operation (preview, update, import, refresh, or destroy).
|
2018-09-05 14:20:25 +00:00
|
|
|
type UpdateOperation struct {
|
2019-04-18 22:57:54 +00:00
|
|
|
Proj *workspace.Project
|
|
|
|
Root string
|
2020-10-14 11:51:53 +00:00
|
|
|
Imports []deploy.Import
|
2019-04-18 22:57:54 +00:00
|
|
|
M *UpdateMetadata
|
|
|
|
Opts UpdateOptions
|
2019-04-24 22:42:39 +00:00
|
|
|
SecretsManager secrets.Manager
|
2023-01-11 16:04:14 +00:00
|
|
|
SecretsProvider secrets.Provider
|
2019-04-18 22:57:54 +00:00
|
|
|
StackConfiguration StackConfiguration
|
|
|
|
Scopes CancellationScopeSource
|
|
|
|
}
|
|
|
|
|
2019-08-12 07:22:42 +00:00
|
|
|
// QueryOperation configures a query operation.
|
|
|
|
type QueryOperation struct {
|
|
|
|
Proj *workspace.Project
|
|
|
|
Root string
|
|
|
|
Opts UpdateOptions
|
|
|
|
SecretsManager secrets.Manager
|
2023-01-11 16:04:14 +00:00
|
|
|
SecretsProvider secrets.Provider
|
2019-08-12 07:22:42 +00:00
|
|
|
StackConfiguration StackConfiguration
|
|
|
|
Scopes CancellationScopeSource
|
|
|
|
}
|
|
|
|
|
2019-04-18 22:57:54 +00:00
|
|
|
// StackConfiguration holds the configuration for a stack and it's associated decrypter.
|
|
|
|
type StackConfiguration struct {
|
2023-10-10 01:35:39 +00:00
|
|
|
Environment esc.Value
|
|
|
|
Config config.Map
|
|
|
|
Decrypter config.Decrypter
|
2018-09-05 14:20:25 +00:00
|
|
|
}
|
|
|
|
|
2018-05-05 18:57:09 +00:00
|
|
|
// UpdateOptions is the full set of update options, including backend and engine options.
|
|
|
|
type UpdateOptions struct {
|
|
|
|
// Engine contains all of the engine-specific options.
|
|
|
|
Engine engine.UpdateOptions
|
|
|
|
// Display contains all of the backend display options.
|
2018-09-04 22:40:15 +00:00
|
|
|
Display display.Options
|
2018-05-05 18:57:09 +00:00
|
|
|
|
|
|
|
// AutoApprove, when true, will automatically approve previews.
|
|
|
|
AutoApprove bool
|
|
|
|
// SkipPreview, when true, causes the preview step to be skipped.
|
|
|
|
SkipPreview bool
|
2024-02-01 20:30:40 +00:00
|
|
|
// PreviewOnly, when true, causes only the preview step to be run, without running the Update.
|
|
|
|
PreviewOnly bool
|
Revise the way previews are controlled
I found the flag --force to be a strange name for skipping a preview,
since that name is usually reserved for operations that might be harmful
and yet you're coercing a tool to do it anyway, knowing there's a chance
you're going to shoot yourself in the foot.
I also found that what I almost always want in the situation where
--force was being used is to actually just run a preview and have the
confirmation auto-accepted. Going straight to --force isn't the right
thing in a CI scenario, where you actually want to run a preview first,
just to ensure there aren't any issues, before doing the update.
In a sense, there are four options here:
1. Run a preview, ask for confirmation, then do an update (the default).
2. Run a preview, auto-accept, and then do an update (the CI scenario).
3. Just run a preview with neither a confirmation nor an update (dry run).
4. Just do an update, without performing a preview beforehand (rare).
This change enables all four workflows in our CLI.
Rather than have an explosion of flags, we have a single flag,
--preview, which can specify the mode that we're operating in. The
following are the values which correlate to the above four modes:
1. "": default (no --preview specified)
2. "auto": auto-accept preview confirmation
3. "only": only run a preview, don't confirm or update
4. "skip": skip the preview altogether
As part of this change, I redid a bit of how the preview modes
were specified. Rather than booleans, which had some illegal
combinations, this change introduces a new enum type. Furthermore,
because the engine is wholly ignorant of these flags -- and only the
backend understands them -- it was confusing to me that
engine.UpdateOptions stored this flag, especially given that all
interesting engine options _also_ accepted a dryRun boolean. As of
this change, the backend.PreviewBehavior controls the preview options.
2018-04-28 21:50:17 +00:00
|
|
|
}
|
|
|
|
|
2019-08-12 07:22:42 +00:00
|
|
|
// QueryOptions configures a query to operate against a backend and the engine.
|
|
|
|
type QueryOptions struct {
|
|
|
|
// Engine contains all of the engine-specific options.
|
|
|
|
Engine engine.UpdateOptions
|
|
|
|
// Display contains all of the backend display options.
|
|
|
|
Display display.Options
|
|
|
|
}
|
|
|
|
|
2018-04-20 01:59:14 +00:00
|
|
|
// CancellationScope provides a scoped source of cancellation and termination requests.
|
|
|
|
type CancellationScope interface {
|
|
|
|
// Context returns the cancellation context used to observe cancellation and termination requests for this scope.
|
|
|
|
Context() *cancel.Context
|
|
|
|
// Close closes the cancellation scope.
|
|
|
|
Close()
|
|
|
|
}
|
|
|
|
|
|
|
|
// CancellationScopeSource provides a source for cancellation scopes.
|
|
|
|
type CancellationScopeSource interface {
|
|
|
|
// NewScope creates a new cancellation scope.
|
|
|
|
NewScope(events chan<- engine.Event, isPreview bool) CancellationScope
|
|
|
|
}
|
2018-05-07 18:49:15 +00:00
|
|
|
|
2018-11-14 21:33:35 +00:00
|
|
|
// NewBackendClient returns a deploy.BackendClient that wraps the given Backend.
|
2023-01-11 16:04:14 +00:00
|
|
|
func NewBackendClient(backend Backend, secretsProvider secrets.Provider) deploy.BackendClient {
|
|
|
|
return &backendClient{backend: backend, secretsProvider: secretsProvider}
|
2018-11-14 21:33:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
type backendClient struct {
|
2023-01-11 16:04:14 +00:00
|
|
|
backend Backend
|
|
|
|
secretsProvider secrets.Provider
|
2018-11-14 21:33:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// GetStackOutputs returns the outputs of the stack with the given name.
|
|
|
|
func (c *backendClient) GetStackOutputs(ctx context.Context, name string) (resource.PropertyMap, error) {
|
|
|
|
ref, err := c.backend.ParseStackReference(name)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
s, err := c.backend.GetStack(ctx, ref)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if s == nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("unknown stack %q", name)
|
2018-11-14 21:33:35 +00:00
|
|
|
}
|
2023-01-11 16:04:14 +00:00
|
|
|
snap, err := s.Snapshot(ctx, c.secretsProvider)
|
2018-11-14 21:33:35 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2019-04-19 17:41:08 +00:00
|
|
|
res, err := stack.GetRootStackResource(snap)
|
2019-04-17 20:48:38 +00:00
|
|
|
if err != nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("getting root stack resources: %w", err)
|
2019-04-17 20:48:38 +00:00
|
|
|
}
|
2018-11-14 21:33:35 +00:00
|
|
|
if res == nil {
|
|
|
|
return resource.PropertyMap{}, nil
|
|
|
|
}
|
|
|
|
return res.Outputs, nil
|
|
|
|
}
|
2019-03-15 22:01:37 +00:00
|
|
|
|
2019-02-15 22:29:55 +00:00
|
|
|
func (c *backendClient) GetStackResourceOutputs(
|
2023-03-03 16:36:39 +00:00
|
|
|
ctx context.Context, name string,
|
|
|
|
) (resource.PropertyMap, error) {
|
2019-02-15 22:29:55 +00:00
|
|
|
ref, err := c.backend.ParseStackReference(name)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
s, err := c.backend.GetStack(ctx, ref)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if s == nil {
|
2021-11-13 02:37:17 +00:00
|
|
|
return nil, fmt.Errorf("unknown stack %q", name)
|
2019-02-15 22:29:55 +00:00
|
|
|
}
|
2023-01-11 16:04:14 +00:00
|
|
|
snap, err := s.Snapshot(ctx, c.secretsProvider)
|
2019-02-15 22:29:55 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
pm := resource.PropertyMap{}
|
|
|
|
for _, r := range snap.Resources {
|
|
|
|
if r.Delete {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
resc := resource.PropertyMap{
|
|
|
|
resource.PropertyKey("type"): resource.NewStringProperty(string(r.Type)),
|
2023-03-03 16:36:39 +00:00
|
|
|
resource.PropertyKey("outputs"): resource.NewObjectProperty(r.Outputs),
|
|
|
|
}
|
2019-02-15 22:29:55 +00:00
|
|
|
pm[resource.PropertyKey(r.URN)] = resource.NewObjectProperty(resc)
|
|
|
|
}
|
|
|
|
return pm, nil
|
|
|
|
}
|
2023-03-17 19:39:45 +00:00
|
|
|
|
2023-03-20 21:30:53 +00:00
|
|
|
// ErrTeamsNotSupported is returned by backends
|
|
|
|
// which do not support the teams feature.
|
|
|
|
var ErrTeamsNotSupported = errors.New("teams are not supported")
|
|
|
|
|
2023-03-20 21:12:17 +00:00
|
|
|
// CreateStackOptions provides options for stack creation.
|
|
|
|
// At present, options only apply to the Service.
|
|
|
|
type CreateStackOptions struct {
|
|
|
|
// Teams is a list of teams who should have access to
|
|
|
|
// the newly created stack.
|
|
|
|
// This option is only appropriate for backends
|
|
|
|
// which support teams (i.e. the Pulumi Service).
|
2023-03-20 21:30:53 +00:00
|
|
|
//
|
|
|
|
// The backend may return ErrTeamsNotSupported
|
|
|
|
// if Teams is specified but not supported.
|
2023-03-20 21:12:17 +00:00
|
|
|
Teams []string
|
2023-03-17 19:39:45 +00:00
|
|
|
}
|