<!---
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 updates the typing annotations and semantics of Python Automation
API inline programs. It's now defined to be a callable that returns an
optional awaitable of `None`. This supports both existing synchronous
functions (should just return `None`) and now also supports async
functions that return an `Awaitable` that eventually resolves to `None`.
## 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
- [x] 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.
-->
- [x] 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. -->
---------
Co-authored-by: Julien P <julien@caffeine.lu>
# Description
Provide a way for the Automation API to install the Pulumi CLI so that
Automation API can be used in a more standalone manner.
https://github.com/pulumi/pulumi/issues/14987
## 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. -->
In preparation for supporting Python 3.12...
The test was installing a `requirements.txt` file that depends on the
released version of the `pulumi` package, but that package depends on
the old `grpcio` package that does not work Python 3.12. Instead of
depending on the public `pulumi` package, install the locally built
Python SDK.
Also, fix the test to be able to run on Windows, while making changes
here.
<!---
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. -->
Dependabot updated some references to this in
https://github.com/pulumi/pulumi/pull/15131. But missed a lot,
importantly it didn't update pkg or sdk which are the most important
modules in this repo.
## Checklist
- [x] 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.
-->
- [x] 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. -->
<!---
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. -->
Automation API support for `pulumi config env ls`
Fixes https://github.com/pulumi/pulumi/issues/14797
## 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. -->
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) to 0.17.0.
Replaces all the dependabot PRs in the repo with this single PR.
Also bumped `github.com/pulumi/pulumi/sdk/v3` in
`tests/integration/transformations/go/simple/go.mod` from v3.97.0 to
v3.98.0 to use esc v0.6.1, and avoid the appdash issue.
<!---
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. -->
Add python automation API support for adding and removing environments
for stack configuration.
Fixes https://github.com/pulumi/pulumi/issues/14793
## 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. -->
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
<!---
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. -->
Currently if no project settings are provided this is the default value
for `main`, but if the caller providers a project_settings object
without this set it will cause a module load issue if the inline program
depends on other local python files. The current work-around is to put
all the code in one file or set `work_dir`.
Fixes#7960
## 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.
-->
- [X] 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. -->
Co-authored-by: Paul Roberts <proberts@pulumi.com>
<!---
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. -->
Currently, when we detect that we've created a cycle in the dependency
graph, we early-exit. This works well enough for simple cycles, but when
early exiting is not sufficient (as when providing a resource output as
an argument to another resource's inputs), we will still fail to resolve
the full dependency graph. This PR introduces an exception-by-default,
as any cycles represent an unsafe/invalid dependency graph and should be
resolved manually. We also provide an escape hatch to fall back to
current behavior, in case users would prefer to retain the ability to
create unsafe dependency graphs (potentially introducing infinite hangs
when resolving those graphs).
Fixes https://github.com/pulumi/pulumi/issues/13551
## 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.
-->
- [x] 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. -->
The hand-rolled invoke code in the Kubernetes Python SDK is not
expecting empty dicts for empty results. Instead, it has code that
checks for `None`.
In general, we want to keep the behavior of returning empty dicts rather
than `None` for empty results, as this aligns with the behavior of other
SDKs (Node.js and Go) and is actually the original behavior of the
Python SDK (it regressed unintentionally in the v2 timeframe).
We're updating the Kubernetes Python SDK to be resilient to either
getting an empty dict or `None` for invokes with empty results.
Additionally, to maintain compat with older versions of the Kubernetes
Python SDK, we'll special case those invoke tokens. When an invoke's
result is empty and the token is one of the Kubernete's function tokens,
we'll return `None` rather than the empty dict.
Fixes#14508
When an empty struct is returned from an invoke, the Python SDK was
returning None, which causes the following error to be raised from
generated provider Python SDKs when calling the invoke:
```
AssertionError: get can only be used with classes decorated with @input_type or @output_type
```
This is because the Python SDK is returning None if the return value
isn't truthy, roughly:
```
ret_obj = getattr(resp, "return")
if ret_obj:
return ret_obj
return None
```
However, an empty struct isn't truthy, so we're returning None in that
case, and generated provider Python SDKs can't handle that.
Other SDKs like the Node.js and Go SDKs don't have this problem.
This commit fixes the issue by removing the `if ret_obj` check, as it's
not necessary. In practice, `ret_obj` is always going to be an instance
of `struct_pb2.Struct` because all monitors (CLI and mock) return an
instance, though the instance may be empty, which is ok.
Fixes#13985
This PR replaces all the dependabot PRs with a single commit that
updates all relevant go.mod files.
This resolves 3 Dependabot alerts on golang.org/x/net including a
moderate severity alert.
This change adds the missing `default` arg to `Config.get_secret`
method, for consistency with the other `get_secret_<type>` methods that
have a `default` arg.
Fixes#12271
<!---
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. -->
Fixes https://github.com/pulumi/pulumi/issues/13997.
It would be a little nicer if every input type _actually_ implemented
the `Mapping` interface, but that trying to do that turned into a much
deeper fix than this one.
## 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.
-->
- [x] 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. -->
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.
We used to test that various errors we're written out to the user in
these langhost tests, but at some point those test were removed (I
suspect because we stopped printing them to stderr).
This adds in the ability to check for a log message in the engine
diagnostics stream, and makes use of that in one of the tests.
Add support to the core SDKs for reporting resource source positions.
In each SDK, this is implemented by crawling the stack when a resource
is registered in order to determine the position of the user code that
registered the resource.
This is somewhat brittle in that it expects a call stack of the form:
- Resource class constructor
- abstract Resource subclass constructor
- concrete Resource subclass constructor
- user code
This stack reflects the expected class hierarchy of "cloud resource /
component resource < customresource/componentresource < resource".
For example, consider the AWS S3 Bucket resource. When user code
instantiates a Bucket, the stack will look like
this in NodeJS:
new Resource (/path/to/resource.ts:123:45)
new CustomResource (/path/to/resource.ts:678:90)
new Bucket (/path/to/bucket.ts:987:65)
<user code> (/path/to/index.ts:4:3)
In order to determine the source position, we locate the fourth frame
(the `<user code>` frame).
13463: Fix links to outputs docs r=cnunciato a=cnunciato
Fixes some broken links pointing to the Inputs & Outputs docs.
Fixes#13461.
Co-authored-by: Christian Nunciato <chris@nunciato.org>
Fixes https://github.com/pulumi/pulumi/issues/7029
For some reason the python RPC serializer explictly disallowed tuple,
despite python codegen outputing types using `Sequence` rather than
`List` suggesting that `tuple` would be acceptable.
A previous attempt to fix this in 5dd813ea47 didn't fully address the problem when there are more complex parent/child relationships with components.
This change fully addresses the problem by using the same cycle detection logic used elsewhere for local components. We now check for cycles up-front and exit early.
When a resource depends on a local component resource, rather than setting the component resource itself as a dependency, each of the component's descendants is added as a dependency. This can lead to hangs when cycles are introduced.
For example, consider the following parent/child hierarchy, where `ComponentA` is the parent of `ComponentB` and `ComponentB` is the parent of `CustomC`:
ComponentA
|
ComponentB
|
CustomC
If `ComponentB` specifies it has a dependency on `ComponentA`, the following takes place as part determining the full set of transitive dependencies:
1. `ComponentA` is a component resource so it isn't added as a dependency, its children are.
2. `ComponentA` has one child: `ComponentB`
3. `ComponentB` is a component resource so it isn't added as a dependency, its children are.
4. `ComponentB` has one child: `CustomC`, a custom resource.
5. Since `CustomC` is a custom resource, it is added to the set of dependencies.
6. We try to await its URN, but we'll never get it because `RegisterResource` hasn't yet been called for it. And we hang waiting.
To address this, skip looking at a component's children if it is the component from which the dependency is being added.
In the example, with the fix, at step 3 the dependency expansion will stop: we won't look at `ComponentB`'s children because we're adding the dependency from `ComponentB`.
PR feedback
12374: whoami: Add --json flag, expose everything in Auto API r=abhinav a=mrod-io
<!---
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
* Adds `--json` flag to `pulumi whoami` (CLI)
* Adds `url` and `organizations` to WhoAmIResult in NodeJS, Go and Python (automation API)
I sanity tested the auto api in the 3 runtimes and the cli output looks like:
```bash
$ pulumi whoami -j
{
"user": "me",
"organizations": [
"me",
"company"
],
"url": "https://app.pulumi.com/me"
}
```
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
Fixes # https://github.com/pulumi/pulumi/issues/10356
## Checklist
<!--- 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.
-->
- [x] 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
12397: Changelog and go.mod updates for v3.57.1 r=abhinav a=pulumi-bot
bors merge
Co-authored-by: Matthew Rodrigues <matthew.rodrigues@starburstdata.com>
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Co-authored-by: github-actions <github-actions@github.com>
12275: Add stack tag support for python automation api sdk r=justinvp a=mrod-io
<!---
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
Adds support for tagging stacks with the Python automation API.
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
Fixes # (issue)
* https://github.com/pulumi/pulumi/issues/11936 (Python support)
## Checklist
<!--- 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.
-->
- [x] 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Matthew Rodrigues <matthew.rodrigues@starburstdata.com>
It's currently possible in Pulumi to pass a ProviderResource
as a Provider option to a ComponentResource.
The ComponentResource will record the Provider for later,
and propagate it to its child resources.
This is currently the behavior in [all SDKs except Python][1].
[1]: https://github.com/pulumi/pulumi/issues/12161#issuecomment-1446864847
The reason this didn't work was because in Python's
providers merging logic, we use the incorrect package name
when saving the provider.
Instead of using the package name reported by the provider,
we were using the package name of the current resource
(the ComponentResource in this case).
To fix this, verify that the package name of the provider
matches the package name of the resource we're building.
If it doesn't, we will still save the provider
for child resources.
Resolves#12161
The MergeResourceOptions test was incorrectly invoking
the static method ResourceOptions.merge as an instance method.
This issue was reported by the type-checker.
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
12071: sdk/py/StackReference: Add get_output_details r=abhinav a=abhinav
This is the Python equivalent to the StackReference.GetOutputDetails
method and accompanying type added to the Go SDK in #12034.
This will allow users of the Python SDK to fetch outputs from stack
references directly--without going through an Output type.
Refs #10839, #5035
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
This is the Python equivalent to the StackReference.GetOutputDetails
method and accompanying type added to the Go SDK in #12034.
This will allow users of the Python SDK to fetch outputs from stack
references directly--without going through an Output type.
Refs #10839, #5035
When the `await RPC_MANAGER.rpcs.pop()` explodes,
the traceback is for `RPC_MANAGER.rpcs.pop()`, e.g.
```
error: Program failed with an unhandled exception:
Traceback (most recent call last):
File "/opt/hostedtoolcache/pulumi/3.43.1/x64/pulumi-language-python-exec", line 179, in <module>
loop.run_until_complete(coro)
File "/opt/hostedtoolcache/Python/3.10.9/x64/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
return future.result()
File "[..]/venv/lib/python3.10/site-packages/pulumi/runtime/stack.py", line 126, in run_in_stack
await run_pulumi_func(lambda: Stack(func))
File "[..]/venv/lib/python3.10/site-packages/pulumi/runtime/stack.py", line 51, in run_pulumi_func
await wait_for_rpcs()
File "[..]/venv/lib/python3.10/site-packages/pulumi/runtime/stack.py", line 73, in wait_for_rpcs
await RPC_MANAGER.rpcs.pop()
RecursionError: maximum recursion depth exceeded
```
This isn't super helpful in debugging these errors.
RPC_MANAGER already tracks uncaught excpetions from such RPCs
but wait_for_rpcs doesn't account for these until aftewards.
This changes wait_for_rpcs to reproduce the original tracebacks
when it encounters errors in waiting for RPCs.
The included test verifies that the more helpful traceback is produced.
Refs #11887