* Do not share maps so tests can run in parallel
* Fix comment
* Try not to break dependencies
* Address PR feedback
* Fix downstream compilation failure
* Fix lint
* Address PR feedback
* Add a test demonstrating the problem
* Fix the bug
* Accept changes over the example set
* Accept go changes
* Accept python codegen; avoid nil lang info panic
* Accept .NET changes, compile
* Accept docs changes
* Add changelog notes
* Fix lint
* Add parens sparingly
* Flatten unions
* PR feedback
* Move program tests into folders
* update package schema
* Enabled tests pass
* Fix lints and begin to update test cases
* Re-enable tests
* Update aws version to v4
* Refactor language specific parts
* Hook up dotnet and nodejs
* Update tests from master
* SSOT for schema/version
* Name blocking errors. Leave tests in valid state
* Give each language its own folder
* Remove SkipCompile for azure-sa (bug was fixed)
* Fix nits + changes asserts to require
* Remove unused import
* One last assert => require
When computing the type name for a field of an object type, we must
ensure that we do not generate invalid recursive struct types. A struct
type T contains invalid recursion if the closure of its fields and its
struct-typed fields' fields includes a field of type T. A few examples:
Directly invalid:
type T struct { Invalid T }
Indirectly invalid:
type T struct { Invalid S }
type S struct { Invalid T }
In order to avoid generating invalid struct types, we replace all
references to types involved in a cyclical definition with *T. The
examples above therefore become:
(1) type T struct { Valid *T }
(2) type T struct { Valid *S }
type S struct { Valid *T }
We do this using a rewriter that turns all fields involved in reference
cycles into optional fields.
These changes also include an enhancement to the SDK codegen test
driver in the interest of making iterating and debugging more convenient: if the -sdk.no-checks flag is passed, the driver will not run post-generation checks.
* Enable output values by default
Enable output values by default in the resource monitor and change the polarity of the envvar from `PULUMI_ENABLE_OUTPUT_VALUES` to `PULUMI_DISABLE_OUTPUT_VALUES`.
* Marshal unknown as unknown string when `!KeepOutputValues`
Marshal all unknown output values as `resource.MakeComputed(resource.NewStringProperty(""))` when not keeping output values, which is consistent with what the SDKs do.
Otherwise, when `v.OutputValue().Element` is nil, `resource.MakeComputed(v.OutputValue().Element)` will be marshaled as a null value rather than as an unknown sentinel.
* Add MarshalOptions.DontSkipOutputs and use where needed
Before we expanded the meaning of `resource.Output`, `MarshalProperties` always skipped output values:
```go
if v.IsOutput() {
logging.V(9).Infof("Skipping output property for RPC[%s]: %v", opts.Label, key)
}
```
As part of expanding the meaning of `resource.Output`, I'd adjusted `MarshalProperties` to only skip output values when the value was unknown and when not keeping output values:
```go
if v.IsOutput() && !v.OutputValue().Known && !opts.KeepOutputValues {
logging.V(9).Infof("Skipping output property for RPC[%s]: %v", opts.Label, key)
}
```
However, this doesn't work the way we want when marshaling properties that include unknown output values to a provider that does not accept outputs. In that case, `opts.KeepOutputValues` will be `false` because we want the marshaler to fall back to returning non-output-values (e.g. unknown sentinel value for unknown output values), but instead of getting the intended fallback values, the unknown output values are skipped (not what we want).
I suspect we may be able to delete the output value skipping in `MarshalProperties` altogether (it's odd that it is skipping `resource.Output` but not `resource.Computed`), but to avoid any unintended side effects of doing that, instead, this commit introduces a new `MarshalOptions.DontSkipOutputs` option that can be set to `true` to opt-in to not skipping output values when marshaling. The check in `MarshalProperties` now looks like this:
```go
if !opts.DontSkipOutputs && v.IsOutput() && !v.OutputValue().Known {
logging.V(9).Infof("Skipping output property for RPC[%s]: %v", opts.Label, key)
}
```
`opts.DontSkipOutputs` is set to `true` when marshaling properties for calls to a provider's `Construct` and `Call`.
* [sdk/nodejs] Deserialize output values
This commit adds support for deserializing output values, which is needed in some cases when serialized inputs are returned as outputs in the SDK.
* [sdk/python] Deserialize output values
This commit adds support for deserializing output values, which is needed in some cases when serialized inputs are returned as outputs in the SDK.
* Multi-pass, in-place checks for SDK codegen tests; toward working Python checks
* Remove temp debug output
* Upgrade Node
* Update dotnet; need to follow up on version.txt quirks
* WIP
* Sounds like we can use non-github package names to ensure things are local
* Fix simple-enum-schema
* Fix dash-named-schema
* Fix nested-module
* Start building a test-running pass
* Infer skipping tests from skipping compiles
* Move tree schma tests to a proper place
* Address lint issues on Go code
* Build against local Go SDK
* Update pkg/codegen/internal/test/sdk_driver.go
Co-authored-by: Ian Wahbe <ian@wahbe.com>
* Make go tests work by copying them into the tree from go-extras
* Fix lint
* Fix bad merge
* Manifest-based file discovery
* Remove version-related TODO from dotnet codegen
* Add doc comment
* Do not overwrite go.mod if found from mixins
* Accept python codegen change
* Accept node codegen
* Ignore lint issue
* Accept docs changes
Co-authored-by: Ian Wahbe <ian@wahbe.com>
This schema can be used to validate the contents of a Pulumi deployment.
If a deployment validates against this schema, it should be considered
syntactically valid, though it may contain certain classes of semantic
errors (e.g. references to unknown resources in dependency lists,
dependency cycles, etc.).
This schema is not yet used for validation in practice and may not be
entirely accurate.
These changes also add this schema (and the schemas on which it depends)
to the developer documentation. jsonschema2md.go has been updated to
support multi-file schemas.
The Pulumi Package metaschema is a JSON schema definition that describes
the format of a Pulumi Package schema. The metaschema can be used to
validate certain basic properties of a Pulumi Package schema, including
(but not limited to):
- data types (e.g. is this property a string?)
- data formats (e.g. is this string property a valid regex?)
- object shapes (e.g. is this object missing required properties?)
The schema binder has been updated to use the metaschema as its first
validation pass.
In addition to its use in the binder, the metaschema has its own page in
the developer documentation. This page is generated using a small tool,
jsonschema2md.go.
* Add pascal name case
* Add test to prevent regressions
* Update CHANGELOG_PENDING.md
* Give node/tsc more memory
* Use camelcase instead of snake case
* Add clearer comments
* Emit schema.Package.Version when possible
* Update CHANGELOG_PENDING.md
* Correctly interpret python versions (I hope)
* Update PLUGIN_VERSION to the package version
* Modify tests to conform with master merge
* Validate Name, Version and Enviroment
For the full path:
Package.Name
Package.Version
Package.Property.Default
* Update tests
* Update CHANGELOG_PENDING.md
* Add more versions to tests
* Add another "Version" field
* Even more "version" tags
* One more "version" tag added
* Update test results from codegen
* Fix py codegen tests
* Fix doc test
* Remove `version` validation
* Unformat json files
* Fail only on errors
We run the best static check we can on generated code, ensuring that it is valid.
* Run type checker against all languages (not docs)
* Fix package location, add some deps for schemas
* More tests passing
* These tests finally work
* Make linter happy
* Fix tests for merge from master
* Opt out of input-collision(nodejs) test
* Get more visibility into testing nodejs
* Fix type assumption
* Specify ts-node version
* Retrofit typescript dependencies for node14
* Give each go instance it's own module
* Attempt to diagnose remote go mod init failure
* Provide root for go mod init
* Make linter happy
This change expands the definition of `resource.Output` in the Go SDK with additional information about the output, i.e. dependencies and secretness, and adds support in the core Go RPC code for (un)marshaling output values.
Output values are marshaled as special objects ala archives, assets, and resource refs and are unmarshaled as `resource.Output` values.
Subsequent PRs will add:
- A monitor feature for output values, which will initially be disabled by default but available to turn on via an envvar
- Support for (un)marshaling output values in each language SDKs
- A way for providers to indicate support for receiving output values
- E2E tests
- Turn the monitor feature on by default (w/ env var to disable) (Note: the current plan is to initially scope this to only be used when marshaling inputs to a multi-language component)
* Added filebase64 support for Golang
* Fixed function signature
* Added filebase64 support for Typescript
* Added filebase64 support for Python
* Added filebase64 support for Dotnet, fixed Sha1
* Fixed helper method list
Co-authored-by: Vova Ivanov <jetvova@gmail.com>
* Fix some nits from 7874
This was a premature merge
* Fix#7940
We don't surface recursion warnings if there is no child where `replaceOnChanges` is set.
* Introduce a test that showcases the invalid generated code
* Use shared printComment function
* Check for triple quote escaping
* Accept go
* Accept dotnet
* Accept nodejs
* Move codegen exampe into an existing schema
* Add CHANGELOG entry
* Add replaceOnChange to schema
* replaceOnChange at generate time for resources
* ReplaceOnChanges sees through optional types
* Correctly deal with map,array,object,resource type
This is responding to PR clarifications from @justinvp and @lblackstone.
* Update CHANGELOG_PENDING.md
* Detect recursively defined objects
* Display recursion warning
* Check which recursive structures fail
* Add internal logic tests for replaceOnChanges
* Add tests
- Change the schema package to report semantic errors as diagnostics
rather than Go errors
- Add a `pulumi schema check` command to the CLI for static checking of
package schemas
The semantic checker can be extended in the future to add support for
target-specific checks.
* Go support for 5758 - resurrect stale PR
* Fix listStorageAccountKeys test
* Check err so linter is satisfied
* Use all the examples
* Accept codegen results
* Regenerate with PULUMI_IGNORE_AMBIENT_PLUGINS=1
* Compile and test generated code as part of the test suite
* Add a CHANGELOG entry
* Remove temp test marker
* Shorten output type name
* Simplify code
* Add issue link
* Accept more codegen changes
* Use the suggested format for linking an issue
Change `pulumi new` to use `go mod tidy` rather than `go mod download` when installing Go project dependencies, to ensure the project is fully prepared to be used by `pulumi up`, avoiding `missing go.sum entry for module` errors.
Fixes deletion order issues outlined in #7780 related to dependencies on multi language components not ensuring that all (transitive) children of the dependency are treated as dependencies.
Since the state file is not guaranteed to include all transitive dependencies explicitly specified (because dependencies on multi-langauge components will only include the dependency on the component itself, not all of it's transitive children), this PR enlightens the computation of dependencies for deletion ordering to expand the transitive dependency to include transitive children of direct dependencies.
A few identically-typed variables got confused with the changes in #7737.
The confusion caused empty property values to be included in resources
that had any dependencies on other resources, which confused the
unmarshaling code for Go multi-language components. These changes fix
the typo and restore the original behavior, which is to omit empty
property values.
Co-authored-by: Emiliza Gutierrez <emiliza@pulumi.com>
Do not return the inputs as the state for update previews that use an
unconfigured provider. Returning the inputs as the state allows the
language SDKs to incorrectly treat unknown properties as known (because
we can't call `Update` on an unconfigured provider, we can't know which
properties are unknown). Users can re-enable the existing behavior by
setting the `PULUMI_LEGACY_PROVIDER_PREVIEW` environment variable to a
truthy value (e.g. `1`, `true`, etc.).
Most users will be unaffected by these changes. The most common programs
that may be affected are those that combine the creation of a managed
Kubernetes cluster with the deployment of applications to that cluster. These
programs generally need to configure a k8s provider instance by constructing
a kubeconfig from the output of the managed k8s cluster. Any changes to the
cluster that cause the kubeconfig to be unknown then cause the provider to
go unconfigured at runtime. Prior to these changes, resources managed by the
k8s provider would have some known outputs in this scenario, as the engine
would treat the resource's input values as its output values. After these changes,
the resource's outputs will be treated as unknown. The most frequent affect
that this has is that applies/stack outputs that depend on the outputs of
a k8s resource managed by a provider with an unknown kubeconfig will not
run/be displayed as `output`s during previews, respectively.
We might be able to improve on this by taking advantage of schema
information and filling in unknown values for properties that do not
exist in the inputs.
Fixes#7521.
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Co-authored-by: Luke Hoban <luke@pulumi.com>
These changes take a step towards simplifying and unifying the
generation of output types in the Go SDKs, especially for pointer,
array, and map outputs. This code was previously duplicated amongst the
various specialized output type generators, which led to inconsistencies
between the various implementaitons.
This is prep work for fixing #7595.
This commit adds a new counterpart to `ComponentMain` which accepts
an options struct for specifying callback functions. Currently it
supports `construct` (for components) and `call` (for methods), but is
extensible in a non-breaking fashion in future to support all other
provider methods as they become useful to implement.
The original `ComponentMain` still exists, though it may be desirable to
deprecate it in future in favor of `MainWithOptions`.
* [backend/filestate] Allow `pulumi stack ls` to see all stacks regardless of passphrase
The information exposed via `pulumi stack ls` does not require being able to decrypt state files, but the existing logic for `pulumi stack ls` with the filestate backend was to fully decrypt the state file anyway, silently skipping any stacks that could not be decrypted. This led to surprising results from `pulumi stack ls`.
After these changes, `pulumi stack ls` with the filestate backend will list *all* stacks that are available. Notably, because there is no notion of "project" scoping in the fielstate backend (yet), `pulumi stack ls` will list all stacks independent of the project name.
Fixes#4798.
This commit adds two new fields to the Node package info struct to
permit setting the plugin name if it differs from the package name, and
the version if it differs from the package version. This was already
supported by the loader.
Coincident with the release of Pulumi 3.0, we updated the provider SDK codegen for Python to no longer use casing tables for translating Python snake_case names to Pulumi camelCase names (and vice versa). Instead, the mapping is encoded in decorators applied on class properties.
Some of the code that was used to generate and use the casing tables has persisted. This commits removes this code, as it's no longer necessary, and will improve the quality of our generated examples.
Collection types nested inside of Input<Union<...>> types need to abide
by the usual rules for collection types nested inside of input types.
These changes replace the use of the generic SimplifyInputUnion with a
.NET-specific simplifyInputUnion that does not remove Input types
inside of a union if those Input types wrap collection types. Retaining
these Input types allows the usual logic for handling
Input<Collection<...> types in typeString to kick in.
Fixes#7569.
- Only build casing tables once per package
- Right-size buffers in name generation
These changes lead to a significant speedup in example gen for
azure-native.
* Allow non-pulumi imports for Node.js
Currently the code generator is assuming that Node.js dependencies are
following a naming scheme that is prefixed with `pulumi/`. If this is
not the case the generated import statement is incorrect.
This commit adds a map `ProviderNameToModuleName` to the language
definition that allows you to map the name of the extracted provider of
a dependency to a module name that the generator now uses to create the
import statement.
* Prepend "pulumi" to import names in Node.js SDK
It is common when writing multi-language components to have a module
name which conflicts with a provider name. This can produce unusable
code, since you cannot simultaneously import a package as `aws` and have
a namespace `aws`, for example.
This commit makes this situation much less likely, by renaming the
imported identifier for providers to `pulumiX` where it would
previously have been `x`.
This has an unfortunate side effect of making the examples in the
documentation slightly uglier, since import statements for third-party
packages are now of the form `import * as pulumiAws from "@pulumi/aws"`.
I don't see a way to discern whether code generation is for SDKs vs
examples however, and short of plumbing that through, I don't see a way
around this, so test expectations are updated accordingly.
Co-authored-by: Ben Schiborr <bschiborr@apple.com>
- Lazily produce conversion failure diagnostics. This lowers the
allocation volume and cuts down on execution time by avoiding the
conversion of source and dest types to strings.
- Add a fast path for union conversions that checks if the source type
is identical to any of the union's element types. Type equality
checks are generally much faster than type conversion checks.
These changes lead to a significant speedup in codegen time in
azure-native.
- Track which languages have been imported for a package. If a language
has already been imported, do not re-run its importers.
- Track which package contexts have been loaded in the Go code
generator, and do not reload a context that already exists.
These changes shave a profound amount of time off of codegen in
azure-native, speeding things up by a factor of 5.
When converting a `schema.InputType` to a `model.Type`, calculate the
resolved form of the type in the schema type system rather than the
model type system. The results are semantically identical, but the
number of type objects that are allocated is much smaller b/c
`model.NewOutputType` no longer allocates.
This deserves a little more explanation.
In order to prevent nested outputs and/or promises, `model.NewOutputType`
calculates the resolved form of its argument prior to allocating a new
`OutputType` value. Calculating the resolved form of the argument is a
no-op if the argument is already fully resolved. Therefore, passing in a
fully-resolved schema type prevents `model.NewOutputType` from
calulating the resolved form, and `model.NewOutputType` will only
allocate the `OutputType` itself instead of the `OutputType` and the
resolved form of any eventuals present in its argument.
This has a _very important_ knock-on benefit: the schema -> model type
translator ensures that given a `schema.Type` instance `T` it will
always return the same `model.Type` instance `U`. This termendously
speeds up type equality checks for complex types, as they will now be
referentially identical.
This change alone gives a significant speedup in azure-native code
generation.
This commit modifies the generation of `setup.py` to use Python
variables as the source for the package version and plugin version
instead of placeholder strings. This has the effect of making the
packages installable via the `-e` flag directly from their source
directory rather than requiring a build step, which is useful while
developing a plugin and examples in tandem.
This commit modifies Go program generation to prevent producing array
and slice object elements as pointers in args structures, which fails at
runtime and does not make sense in any case. For example, in the case of
a type defined like this in schema:
```json
"statements": {
"type": "array",
"items": {
"$ref": "/aws/v4.8.0/schema.json#/types/aws:iam/getPolicyDocumentStatement:getPolicyDocumentStatement"
}
},
```
The following (which fails at runtime) was produced before this change:
```go
Statements []*iam.GetPolicyDocumentStatement `pulumi:"statements"`
```
And the following is produced after after this change:
```go
Statements []iam.GetPolicyDocumentStatement `pulumi:"statements"`
```
Test expectations are updated accordingly.
This commit fixes code generation for intermediate module paths to
produce valid TypeScript identifiers.
Before this change, the following (non-compilable) import was produced
in `./jetstack/certmanager/acme`:
```
import * as jetstack/certmanager/acme/v1alpha2 from "./jetstack/certmanager/acme/v1alpha2";
```
After this change, the following import is produced:
```
import * as v1alpha2 from "./v1alpha2";
```
This example is repeated at each level of the module tree. Test
expectations are adjusted to reflect this change.
This commit modifies the Go code generator to use configured aliases for
the root package name of a Go module. This is useful when a version 2
package is present, as it prevents generation of identifiers such as
"v2" which were produced by the old logic.
These changes add support for unmarshaling and marshaling package
schemas using YAML instead of JSON. Language-specific data is
canonically JSON. Users of the `*Spec` types will need to update the
types of the the their `Language` values to use the new
`schema.RawMessage` type instead of `json.RawMessage`: the former has
support for YAML while the latter does not.
