The schema specifies supported environment variables
for Provider inputs, but these are not currently reflected
in the generated docs. This change adds any supported
environment variables to the input property comment
field on Provider resources.
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
This way, the tests use the built-in virtual environment support by
default, which is what most customers will be using. A new `UsePipenv`
option is available to go back to using pipenv for tests.
We previously looked for `python3` and fallback to `python` on all systems. However, our Windows CI images include a `python3.exe` symlink to `python.exe` which does not work with `venv`. So on Windows, just look for `python` first, falling back to `python3`. (The default python.org Windows installation only includes `python.exe`).
Update Python tests to use `UseAutomaticVirtualEnv` and set `PythonBin` to `python` on Windows because `python3` doesn't work correctly in the GitHub Action runners.
This fixes not picking up linting issues when sending a PR as
the PR job uses `pull_request_target` which in turn only checks out
from master which is a security measure
Adds a `--limit` flag to `pulumi stack history. This allows limiting to the last few entries rather than fetching the entirety of a stack's update history (which can be quite slow for stacks with lots of updates). Example: `pulumi stack history --limit 1` fetches the last history entry only.
`stack.up` and related operations in the Automation API have been updated to consume this change, drastically reducing overhead.
Fixes: #6185
This PR also addresses the fact that we create an image of
pulumi-nodejs:latest and then the ubi and debian builds override
that pulumi-nodejs:latest with their versions
this overwrite is actually last container wins. Therefore, we will
not be tagging the ubi and debian builds with latest to ensure that
latest is *actually* deterministic
`Output.from_input` deeply unwraps nested output values in dicts and lists, but doesn't currently do that for the more recently added "input types" (i.e. args classes). This leads to errors when using args classes with output values with `Provider` resources, which uses `Output.from_input` on each input property and then serializes the value to JSON in an `apply`. This changes fixes `Output.from_input` to recurse into values within args classes to properly unwrap any nested outputs.
Promise leak debugging was accidentally toStringing an Output, leading to a red herring for several users trying to understand what was causing promise leaks.
Related to #6153 and #5853.
