These changes add two commands for managing a stack's environments:
- `pulumi config env add`, which adds environments to a stack's import
list
- `pulumi config env rm`, which removes an environment from a stack's
import list
As implied by their paths, these commands hang off of a new sub-command
of `pulumi config`, `pulumi config env`.
From the usage:
* `pulumi config env add`
Adds environments to the end of a stack's import list. Imported
environments are merged in order per the ESC merge rules. The list of
stacks behaves as if it were the import list in an anonymous
environment.
* `pulumi config env rm`
Removes an environment from a stack's import list.
Each of these commands previews the new stack environment and shows the
environment definition. These commands print a warning if the stack's
environment does not define any of the `environmentVariables`, `files`,
or `pulumiConfig` properties.
<!---
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
This exposes a GitRepo option to enable shallow cloning repositories.
This is helpful in cases where the repo has a large history.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] 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. -->
- [ ] 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. -->
These changes add support for ESC environments to the Pulumi CLI. This
involves two major changes:
- Support for the `env` subcommand
- Support for the `environment` stanza in stack config files
The former reuses the command from `esc` itself with a little
rebranding.
The latter adds support to stack config files for an `environment`
property of the form:
```yaml
environment:
- list
- of
- environment
- names
```
If this property is present in a stack's config file, the CLI will open
the and merge the listed environments during `pulumi up` et. al. If an
object-valued `pulumiConfig` property is present in the opened
environment, its values will be merged on top of the stack's config
prior to whatever operation is to be performed. If an object-valued
`environmentVariables` property is present inthe opened environment, its
values will be published as environment variables prior to the Pulumi
operation. Any values in the open environment's `pulumiConfig` or
`environmentVariables` that are marked as secret will be encrypted in
the resulting config and will be filtered from the command's logs.
This PR implements the new policy transforms feature, which allows
policy packs to not only issue warnings and errors in response to policy
violations, but actually fix them by rewriting resource property state.
This can be used, for instance, to auto-tag resources, remove Internet
access on the fly, or apply encryption to storage, among other use
cases.
These changes replace the idiosyncratic implementation of some of the
config Map and Value APIs with (hopefully) more straightforward code.
The fundamental representation of a config.Value remains a (value,
secure, object) tuple, where value is either a plain, possible-encrypted
string value or the JSON encoding of an object value. All operations on
values that need to observe the object value itself still decode the
JSON representation into a richer representation. This richer
representation, however, is no longer composed of `any` values: instead,
it is composed of `object` values. These values contain a restricted set
of types and directly track whether or not their contents are a secure
string value. The object-based representation allows for much clearer
implementations of the marshaling and traversal code without breaking
compatibility.
In addition to the new implementation for config.Value, these changes
add a config.Plaintext type that represents a plaintext config value. A
Plaintext value can be created manually or by decrypting a Value, and
can be encrypted and converted to a Value. This allows for more natural
creation and manipulation of config values.
Switch the cmdutil.ReadConsole and cmdutil.ReadConsoleNoEcho functions
to use the bubbletea library to render the prompt,
using the textinput widget provided by the accompanying bubbles library.
The resulting input widgets support arrow keys, back space,
and some basic readline-style bindings including Ctrl-A, Alt-B, etc.
I went through all uses of ReadConsole or ReadConsoleNoEcho.
Only the one in new.go had a non-compliant prompt that I had to adjust.
Note: One divergence in behavior I opted for was that
password prompts will echo '*' characters as the user is typing
and then no echo once they've accepted or canceled the value.
Previously, the prompt did not echo anything in either case.
<details>
<summary>
Introduction if you're unfamiliar with bubbletea
</summary>
bubbletea operates by modeling the widget state as
an immutable data structure that receives messages for events.
On receiving a message (key press, e.g.) the model's Update method
returns a new model instance representing its new state.
Update may also optionally return additional commands for the program,
e.g. stop running, or print something and move on.
The model's View method returns what should be drawn in the terminal
based on the model's current state.
This programming model makes it reasonably straightforward to unit test
some of the core functionality of independent widgets
as demonstrated in this PR.
</details>
Resolves#1565
---
Demos:
<details>
<summary>Plain text</summary>

</details>
<details>
<summary>Secret</summary>

</details>
<details>
<summary>Secret prompt with padding</summary>

</details>
Updates to the latest versions of
google.golang.org/genproto and google.golang.org/grpc
in all submodules in the repository.
This is necessary because in a recent change,
genproto split out some of its subpackages into independent submodules.
(https://github.com/googleapis/go-genproto/issues/1015)
As a result of this, some users may see the error:
```
google.golang.org/genproto/googleapis/rpc/status: ambiguous import: found package google.golang.org/genproto/googleapis/rpc/status in multiple modules:
google.golang.org/genproto v0.0.0-20230410155749-daa745c078e1 (/home/runner/go/pkg/mod/google.golang.org/genproto@v0.0.0-20230410155749-daa745c078e1/googleapis/rpc/status)
google.golang.org/genproto/googleapis/rpc v0.0.0-20230725213213-b022f6e96895
```
Because pu/pu is using 20230410155749,
which has googleapis/rpc as a subpackage,
but another dependency references the independent submodule (20230725213213),
so the system doesn't know which module to use for the import path,
google.golang.org/genproto/googleapis/rpc/status.
This is a problem for codegen tests and ProgramTest-based tests
for Pulumi Go programs that do not have a go.mod in the test directory.
This issue was encountered by @thomas11 while attempting to upgrade
dependencies in pulumi-docker (pulumi/pulumi-docker#700).
The grpc upgrade is necessary because the current version of grpc
also pulls the outdated version of genproto.
The Node SDK creates a tmp file when packing programs, to house
the packed tarball. We previously used uuid to create our own
tmpfile with a random name. This commit uses os.tempfile instead.
The stdlib function os.tempfile is race safe, collision-proof, and
defaults to a tmp directory, which the OS is free to automatically
clean up in case Pulumi fails to.
This changes codegen to be invoked via gRPC from pkg, rather than
invoking pkg/codegen directly.
Consider it a proof-of-concept for moving codegen to a gRPC interface
without the worries of forwards-backwards compatability (because we ship
language plugins at a fixed version side-by-side to users).
Per team discussion, switching to gofumpt.
[gofumpt][1] is an alternative, stricter alternative to gofmt.
It addresses other stylistic concerns that gofmt doesn't yet cover.
[1]: https://github.com/mvdan/gofumpt
See the full list of [Added rules][2], but it includes:
- Dropping empty lines around function bodies
- Dropping unnecessary variable grouping when there's only one variable
- Ensuring an empty line between multi-line functions
- simplification (`-s` in gofmt) is always enabled
- Ensuring multi-line function signatures end with
`) {` on a separate line.
[2]: https://github.com/mvdan/gofumpt#Added-rules
gofumpt is stricter, but there's no lock-in.
All gofumpt output is valid gofmt output,
so if we decide we don't like it, it's easy to switch back
without any code changes.
gofumpt support is built into the tooling we use for development
so this won't change development workflows.
- golangci-lint includes a gofumpt check (enabled in this PR)
- gopls, the LSP for Go, includes a gofumpt option
(see [installation instrutions][3])
[3]: https://github.com/mvdan/gofumpt#installation
This change was generated by running:
```bash
gofumpt -w $(rg --files -g '*.go' | rg -v testdata | rg -v compilation_error)
```
The following files were manually tweaked afterwards:
- pkg/cmd/pulumi/stack_change_secrets_provider.go:
one of the lines overflowed and had comments in an inconvenient place
- pkg/cmd/pulumi/destroy.go:
`var x T = y` where `T` wasn't necessary
- pkg/cmd/pulumi/policy_new.go:
long line because of error message
- pkg/backend/snapshot_test.go:
long line trying to assign three variables in the same assignment
I have included mention of gofumpt in the CONTRIBUTING.md.
12197: deps: Upgrade to pgregory.net/rapid v0.5 r=abhinav a=abhinav
The 0.5 release of rapid exposes a generics-based API
instead of `interface{}` and casting everywhere.
This makes for much cleaner usage.
There are a handful of cases where strongly typed generators,
e.g. `Generator[bool]`, need to be turned into `interface{}` (`any`),
which is doable with `AsAny()`.
API changes:
The only non-test changes to the SDK package are in
go/common/resource/testing, which contains testing utiltiies.
Functions that previously returned the old, untyped `Generator`
now return a strongly typed `Generator[T]`.
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Upgrades all go.mod files to v0.7.0 of golang.org/x/net.
This will take care of the disparate dependabot updates we're receiving
for these files.
See also https://github.com/pulumi/pulumi/security/dependabot/151
Refs CVE-2022-41723
The 0.5 release of rapid exposes a generics-based API
instead of `interface{}` and casting everywhere.
This makes for much cleaner usage.
There are a handful of cases where strongly typed generators,
e.g. `Generator[bool]`, need to be turned into `interface{}` (`any`),
which is doable with `AsAny()`.
API changes:
The only non-test changes to the SDK package are in
go/common/resource/testing, which contains testing utiltiies.
Functions that previously returned the old, untyped `Generator`
now return a strongly typed `Generator[T]`.
This is approach needs to occur in `resmon` since `*resmon` dispatches
`Construct` calls directly.
TS: Send providers map for all components
Ensure that `providers` is passed in all SDKs
The .NET SDK already does the right thing
Add golang integration test
Add local dependency
Fix test
Use new test
Get test working
Fix nits