pulumi/cmd/pulumi-test-language/testdata
Zaid Ajaj f146c2e688
[PCL] Implement package descriptor blocks to support parameterized packages (#17589)
### Description

As part of fixing
https://github.com/pulumi/pulumi-converter-terraform/issues/186 we need
to be able to express resources and packages in PCL that are coming from
parameterized providers.

Today in PCL we will extract the package name from the token of a
resource definition and load that package based on the name (using
`LoadReference`) . For parameterized packages, this will not work
because the schema of the parameterized resource is only available after
we figure out which base provider is being parameterized and what the
parameters are.

In this PR we fix this problem by implementing top-level `package`
blocks that are full package descriptors that contain sufficient
information to load both classic resource plugins and parameterized
packages. The block will looks like:
```tf
package <name> {
  baseProviderName = <name>
  baseProviderVersion = <version>
  baseProviderDownloadUrl = <url>
  parameterization {
      name = <name>
      version = <version>
      value = <base64-encoded-value>
  }
}
```
Example of a package descriptors for a `terraform-provider` provider
parameterized with `hashicorp/random`:
```tf
package "random" {
    baseProviderName = "terraform-provider"
    baseProviderVersion = "0.0.27"
    parameterization {
        name = "random"
        version = "3.6.2"
        value = "eyJyZW1vdGUiOnsidXJsIjoicmVnaXN0cnkub3BlbnRvZnUub3JnL2hhc2hpY29ycC9yYW5kb20iLCJ2ZXJzaW9uIjoiMy42LjIifX0="
    }
}

resource "randomPet" "random:index/pet:Pet" { 
    length = 10 
}
``` 
Now when we extract the package name from `random:index/pet:Pet =>
random` we check if there is a package descriptor for it and use that
descriptor to load the package, parameterizing the base provider when
necessary. Otherwise if the package name doesn't have a descriptor, we
fallback to old package loader that expects plugin
`pulumi-resource-<packageName>` to be available in the plugin cache or
PATH.

These blocks are not mapped to specific `Program` nodes, they are read
from the AST after the PCL files have been parsed.
This information can be easily made available to `pcl.Program` if needed
since it has access to the source binder.

### Conformance Tests

With the ability to parameterize packages from a PCL program, we can
support conformance testing parameterized providers! I've implemented a
new test `l2-parameterized-resource` which implements a parameterized
provider that has a schema and runtime behaviour dictated by the values
it was parameterized with.


### Test this locally
You can test this locally with different parameterized providers, you
will need their parameter values which you can retrieve from the schema:
```
pulumi package get-schema terraform-provider hashicorp/random > random-schema.json
```
In `random-schema.json` you will find values you need in
`$.parameterization`

### Converted Code

The program above can be successfully converted to TypeScript for
example and generates the following:
```ts
import * as pulumi from "@pulumi/pulumi";
import * as random from "@pulumi/random";

const randomPet = new random.Pet("randomPet", {length: 10});
```
This program loaded the parameterized schema and used it to generate the
resource definition correctly.

However the following still need to be addressed:
- The `pulumi convert` doesn't generate the local SDKs are part of the
conversion. Doing this might make
https://github.com/pulumi/pulumi-converter-terraform/issues/186 a lot
easier than expected. cc @brandonpollack23
- Program generators do not understand parameterized packages so they
reference them like any of our provider sdk `"@pulumi/random": "3.6.2"`
(this is wrong because there is not such sdk on npm). They should expect
the SDK to be available locally and reference it via a relative path
 - ~We need a good way to (conformance) test these~ DONE 
2024-11-05 00:58:48 +00:00
..
internal-bad-schema Parse conformance programs to decide which packages are needed for SDKs (#16872) 2024-08-05 12:07:06 +00:00
l1-builtin-info Add an `organization` intrinsic to PCL (#16948) 2024-08-19 03:58:19 +00:00
l1-empty Add matrix testing (#13705) 2023-09-13 15:17:46 +00:00
l1-main/subdir Add asset/archive to conformance tests and fix engine working dir issues (#16100) 2024-05-02 11:32:54 +00:00
l1-output-array Add array conformance test (#15899) 2024-04-10 16:00:24 +00:00
l1-output-bool Add matrix testing (#13705) 2023-09-13 15:17:46 +00:00
l1-output-map Add l1-output-map conformance test (#17301) 2024-09-19 10:08:31 +00:00
l1-output-number Use exact IEEE double min and max values in output test (#16943) 2024-08-12 14:46:41 +00:00
l1-output-string Test string outputs in conformance tests (#15823) 2024-03-29 14:24:29 +00:00
l1-stack-reference Add StackReference conformance test (#15935) 2024-04-16 11:13:25 +00:00
l2-destroy Allow multiple updates in a single conformance test (#15504) 2024-03-01 12:20:12 +00:00
l2-engine-update-options allow engine options to be passed in conformance tests (#15496) 2024-02-23 12:47:02 +00:00
l2-explicit-provider Add explict provider test to conformance tests (#16362) 2024-06-11 14:56:08 +00:00
l2-failed-create-continue-on-error Implement up --continue-on-error (#15740) 2024-04-22 11:12:45 +00:00
l2-invoke-dependencies [sdk/python] Send plain values to the engine in output invokes and keep track of input dependencies/secrets (#17460) 2024-10-04 18:42:11 +00:00
l2-invoke-secrets [sdk/python] Send plain values to the engine in output invokes and keep track of input dependencies/secrets (#17460) 2024-10-04 18:42:11 +00:00
l2-invoke-simple Add a conformance test for invokes (#16867) 2024-08-05 04:32:07 +00:00
l2-invoke-variants Add a conformance test for invokes (#16867) 2024-08-05 04:32:07 +00:00
l2-large-string Add large string conformance test (#16034) 2024-04-25 08:14:34 +00:00
l2-map-keys Add a conformance test for preserving map keys (#17350) 2024-10-11 13:34:46 +00:00
l2-parameterized-resource [PCL] Implement package descriptor blocks to support parameterized packages (#17589) 2024-11-05 00:58:48 +00:00
l2-plain Add plain properties conformance test (#17411) 2024-09-30 16:48:34 +00:00
l2-primitive-ref Add l2-primitive-ref conformance test (#17302) 2024-09-24 08:42:24 +00:00
l2-provider-grpc-config Cover configure (#17508) 2024-10-11 02:23:59 +00:00
l2-provider-grpc-config-schema-secret Language conformance for gRPC Check/Configure with schema-based secrets (#17634) 2024-10-31 14:27:17 +00:00
l2-provider-grpc-config-secret Cover configure (#17508) 2024-10-11 02:23:59 +00:00
l2-ref-ref Add ref-ref conformance test (#17367) 2024-09-26 22:00:55 +00:00
l2-resource-alpha Conformance test for provider pre-release versions (#16498) 2024-06-29 10:07:14 +00:00
l2-resource-asset-archive Add conformance tests for remote assets (#16467) 2024-07-03 09:03:24 +00:00
l2-resource-config Ensure internal provider state doesn't clash with user config (#16837) 2024-07-30 12:22:32 +00:00
l2-resource-primitives Add a test of sending primitive values for a resource (#16718) 2024-07-22 21:13:11 +00:00
l2-resource-simple Add matrix testing (#13705) 2023-09-13 15:17:46 +00:00
l2-target-up-with-new-dependency Make sure non-targeted resources are not updated (#15476) 2024-03-05 07:49:11 +00:00
snapshots Fix folder archives in the engine (#16119) 2024-05-06 07:26:48 +00:00
snapshots_bad Test GetDependencies and library versions in conformance testing (#15324) 2024-02-06 12:38:44 +00:00
snapshots_edit Add snapshot edit facilities to conformance testing (#15747) 2024-03-21 15:26:58 +00:00
snapshots_runtime_options/projects/l1-empty Test runtime options in conformance tests (#15288) 2024-01-29 07:32:11 +00:00