Rotating a passphrase requires that the old passphrase is available via
one of the `PULUMI_CONFIG_PASSPHRASE` or `PULUMI_CONFIG_PASSPHRASE_FILE`
environment variables. This confuses `readPassphrase` when reading a new
passphrase, since that function checks the aforementioned environment
variables prior to reading from the console. The overall effect is that
it is impossible to rotate the passphrase for a stack using the
passphrase provider. These changes fix this by always reading from the
console when rotating a passphrase.
This commit moves from simply asserting on the assignability of types to
using `Assertf` to print the types in question. This provides more
information to a user whose code is panicking because of
non-assignability.
Ultimately it would likely be better to surface this via error messages
instead of via panic, but this at least improves the debuggability in
the meantime.
This command converts an appdash trace into a pprof file for use with
`go tool pprof`. Spans are converted into stacks by sampling each root
span at a given rate and recording the stack of subspans at each sample.
These changes also replace the conditional addition of experimental and
debug commands with conditional visibility. Experimental and debug
commands will always be available, but will be hidden unless the
appropraite environment variables are set.
Co-authored-by: Levi Blackstone <levi@pulumi.com>
* Add trace proxying to fix sub-process trace collection when tracing to files
* Better func naming in test
* Avoid dealing with Windows path nightmare
* On Windows it is go.exe of course
* Rename operation to component to better align with existing trace output
This change is a simple perf optimization to speed up the process of listing plugins by excluding some metadata like size by default.
Our strategy for finding a plugin is to first look on the path, and then to iterate through all plugins in the plugin cache (a directory). We do this for each plugin that is loaded when NewProvider is called. Unfortunately, the codepath that gets all plugins is shared by pulumi plugin ls that needs to do things like display the total size of all plugins, the size of each plugin, and when the plugin was last installed/last used.
This means that any time a plugin is loaded, we are computing the size of all plugins by recursively enumerating all folder (including all of the node_modules directories of any installed node multi-lang plugins!). For my 5 gb of node plugins this translated to 10s of overhead each time a plugin was loaded.
This change is a very simple fix. pulumi plugin ls is the only code path that uses size, so we create a dedicated code path GetPluginsWithMetadata that populates that info, excluding from the result of GetPlugins by default.
* Send plugin install output to stderr
We currently send plugin install output to stdout. This interferes
with --json (#5747), automation API scenarios, and in general is bad
CLI hygiene. This change sends plugin output to stdout instead.
* Add a changelog entry
Temporarily disable the new config secret warning to avoid unactionable warnings from provider `config` modules. We'll re-enable the warning when we've addressed that issue.
The Pulumi Go SDK does not currently await all outstanding asynchronous
work associated with a Pulumi program. Because all relevant asynchronous
work is created via the Pulumi SDK, we can track this asynchronous work
and ensure that it has all completed prior to returning from
`Context.Run`.
This is complicated by the fact that many of the existing APIs that are
able to create `Output`s--`NewOutput`, `ToOutput`, `Any`, `ToSecret`,
and `All`--do not have a `*Context` parameter, and so have no
straightforward way to associate themselves with a `*Context`. To address
this, these changes add new versions of each of these APIs as methods on
`*Context`.
Despite these new methods, most Pulumi programs should work without
changes: the bulk of `Output`s are created by the SDK itself as part of
resource registration, and for `Any` and `All`, we can pick up the
context from any `Output`s present in the arguments. The only programs
that should require changes are those that create outputs from whole
cloth using `NewOutput`, `ToOutput`, or `ToSecret` and create unawaited
async work rooted at those outputs.
On an implementation level, these changes track asynchronous work using
a `sync.WaitGroup` associated with each `*Context`. This `WaitGroup` is
passed to each output associated with the context. The SDK increments
this `WaitGroup`'s count prior to starting any asynchronous work and
decrements it once the work (including any callbacks triggered by the
work) is complete.
This fixes the Go portion of #3991.
* Propagate workspace.Project metadata to plugin init
* Get to a working fix
* Propagate Root via plugin context
* Propagate root instead of yaml path
* Revert out unnecessary parameter propagation
* Root is now always absolute at this point; simplify code and docs
* Drop python conditional and propagate unused -root to all lang hosts
* Add tests that fail before and pass after
* Lint
* Add changelog entry
Config values that are objects are represented in memory as JSON strings. When a config map is being saved to a file, object values are first unmarshaled from JSON to `interface{}` and then the entire config map is marshaled to YAML (or JSON) and saved to disk. When an object value is unmarshaled from JSON, any numbers in the JSON string were being implicitly unmarshaled as `float64`, which resulted in some numbers in the nested objects being emitted in YAML using exponential notation (e.g. a number `12321123131` in an object value was being saved in the YAML as `1.2321123131e+10`). To address this, when unmarshaling the JSON for an object value, first try to unmarshal any numbers as `int64`, falling back to `float64`.
This commit makes it possible to opt out of loading plugins from PATH by
setting PULUMI_IGNORE_AMBIENT_PLUGINS to any non-empty value. This is
useful when automatic IDE tooling may build remote component plugins
into GOBIN unbeknownst to the user, and a resulting stale version of the
plugin is loaded in place of newer versions - even those , explicitly
installed.
When calling l.GetEnvVars() to evaluate whether version checking should
be skipped because of variables passed into the workspace, they have not
yet been set. This commit modifies the logic to look at the environment
variables in the options instead of in the workspace.
Since the original functionality has not yet been released, I do not
believe it warrants a CHANGELOG entry.
