Parameterization refers to the ability for a provider to vary its schema
based on a parameter that is passed to a new `Parameterize` call on the
provider interface. The package reference that is returned may then be
used to interact with the bespoke schema/packages within.
Paramterization is key to e.g. dynamically bridging providers. In this
instance we can manage and release a single "bridge" provider that
accepts a parameter defining the upstream provider to bridge, and
returns a reference to a dynamically constructed package whose schema
reflects the upstream as needed.
In this commit, we extend the engine so that `Call` calls can accept a
package reference and thus be parameterized.
This method already returns 4 different values, and we want to add more.
Refactor it so it returns a struct, to make adding additional return
values easier in the future.
<!---
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. -->
Adds argsDependencies support to the deploytest resource monitor and add
some tests that the engine fills that map in with output values from
args if the SDK hasn't filled it in.
We also need to do this the other way (if the SDK fills in
argsDependencies but doesn't send output<T> values with those deps to
args).
## 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. -->
<!---
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. -->
Similar to what we did to the `InvokeRequest` a while ago. We're
currently using the same protobuf structure for `Provider.Call` and
`ResourceMonitor.Call` despite different field sets being filled in for
each of them.
This splits the structure into `CallRequest` for providers and
`ResourceCallRequest` for the resource monitor. A number of fields in
each are removed and marked reserved with a comment explaining why.
## 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. -->
- [ ] 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 only real change here is a new test in
pkg/engine/lifecycletest/pulumi_test.go and the small fix up to the
`deploytest.ResourceMonitor` to return the information needed for that
test.
deploytest.ResourceMonitor currently zeroes out any custom timeout value
smaller than 60 seconds because it does integer division on it.
Further, it alawys uses a non-nil CustomTimeouts
even when the input was nil.
This causes undesirable breaks in unit tests that use this type.
This change fixes both issues in CustomTimeouts. Now:
- The RegisterResourceRequest.CustomTimeouts field is non-nil
only if the input CustomTimeouts was non-nil
- time.Duration and float divison is used to accurately format
the specified duration as a string
Another step towards #11808.
ResourceMonitor.Call calls ResourceMonitorClient.Call
and converts the output into a few different results.
During the conversion, it builds a `map[PropertyKey][]URN`,
but it never fills that map with values,
and instead always returns the empty map.
This bug was caught by staticcheck.
```
resource/deploy/deploytest/resourcemonitor.go:390:11: SA4010: this result of append is never used, except maybe in other appends (staticcheck)
```