Besides the explicitly provided resources from the `dependsOn` option,
we need to also take into account the resource dependencies from the
invoke’s arguments.
Nodejs implementation of #18133
DependsOn for resources is an ordering constraint for register resource
calls. If a resource R1 depends on a resource R2, the register resource
call for R2 will happen after R1. This is ensured by awaiting the URN
for each resource dependency before calling register resource.
For invokes, this causes a problem when running under preview. During
preview, register resource immediately returns with the URN, however
this does not tell us if the resource "exists".
Instead of waiting for the dependency's URN, we wait for the ID. This
tells us that whether a physical resource exists (if the state is in
sync), and we can avoid calling the invoke when it is unknown.
The following example fails without this change:
```typescript
import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";
const config = new pulumi.Config()
const billingAccountId = config.require("billing-account")
const billingAccount = gcp.organizations.getBillingAccountOutput({
billingAccount: billingAccountId
})
const project = new gcp.organizations.Project("project", {
billingAccount: billingAccount.id,
name: "project-nodejs",
autoCreateNetwork: false,
deletionPolicy: "DELETE",
})
export const zones = gcp.compute.getZonesOutput({
project: project.projectId,
region: "us-central1"
}, {
dependsOn: [project],
})
```
Currently when setting a mock monitor, we only set it in a local
variable. Unfortunately it is possible for multiple @pulumi/pulumi
modules to be loaded at the same time. This means one of them might have
the mock monitor loaded, while the other versions don't, resulting in
confusing behaviour for the user.
Fix this by setting the mock monitor in the global settings, so it's
available in all versions of the SDK.
Fixes https://github.com/pulumi/pulumi/issues/12141
This takes https://github.com/pulumi/pulumi/pull/16392 and updates local
SDK generation for nodejs and adds parametrisation support for invokes
---------
Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Will Jones <will@sacharissa.co.uk>
Rather than saving package/module registrations in a module variable,
save them in the store where other state is stored. This way, if there
are multiple copies of `@pulumi/pulumi`, they'll use the same store,
rather than having separate copies of registrations.
Fixes#13223
---------
Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
From SDKs, we call invokes in one of two ways:
* In a "non-output" context (e.g. `getX`), which has a result dependent
on the language (e.g. a `Promise` in NodeJS) that _does not_ track
dependencies.
* In an "output" context (e.g. `getXOutput`), which has an `Output` type
and does track dependencies.
In the non-output case, `dependsOn` really doesn't make sense, since
this style of invoke is inherently ignoring dependency tracking/outputs.
This commit thus reverts 492c57c7dd so
that we can rethink the design before people's programs are subtly
broken in this case.
This commit adds support for passing `dependsOn` to invokes (whether
streamed or not) in the NodeJS SDK. This allows programs to ensure that
certain invokes are executed after things they depend on, even if that
dependency is not implicitly captured with an input-output relationship.
Part of #14243
As @denbezrukov notes in #13885, Rome (https://github.com/rome/tools,
the JavaScript toolchain we have been using to format and lint code in
the NodeJS SDK) has been deprecated. Biome (https://biomejs.dev/) has
sprung up in its place as a community fork and appears to be the best
bet for migration going forward. This commit introduces Biome, ports the
bits of configuration that need changing and updates formatting
accordingly.
Closes#13885
Co-authored-by: Denis Bezrukov <6227442+denbezrukov@users.noreply.github.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. -->
Fixes#11719
NodeJS now accepts unknown resource IDs for read resource.
## 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. -->
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).
This commit applies the Rome autoformatter to the Node SDK.
These changes are automatically produced. To reproduce these
changes, run `make format` from inside sdk/nodejs.
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 case of the example, at step 3 the dependency expansion will stop: we won't look at `ComponentB`'s children because we're adding the dependency from `ComponentB`.
fix
previously, when both index.ts and index.js were present
and no main key was provided in Pulumi.yaml, Pulumi would quietly
resolve the entrypoint as index.js. This messages that decision in a warning
* Stop using Get/SetRootResource in nodejs
Just use globalThis to make the stack resource a global rather than a module variable. This ensures that even if we end up with multiple Pulumi modules they can all grab the stack object and read URN off it.
We'll keep calling SetRootResource so old modules SxS continue to pickup the stack URN, at some point (4.0 probably) we can clean all this up.
Note that we also need the stack resource to be global for stack transformations, the roundtripping of the URN via the engine didn't preserve those.
* Update CHANGELOG
* Try to resovle circular module imports
* Remove comment
* Readd comment, remove unneeed await
* Fix comments
* Get rid of getRootResource, just pass parent down explictly
* Fix stack parents
* Add stack transform test
* [sdk/nodejs] Pickup provider as part of providers
* Update CHANGELOG_PENDING.md
* Add langhost test
* Handle empty providers
* Fix and expand test
* Make linter happy
Adds a new resource option to force replacement when certain properties report changes, even if the resource provider itself does not require a replacement.
Fixes#6753.
Co-authored-by: Levi Blackstone <levi@pulumi.com>
* Make `async:true` the default for `invoke` calls (#3750)
* Switch away from native grpc impl. (#3728)
* Remove usage of the 'deasync' library from @pulumi/pulumi. (#3752)
* Only retry as long as we get unavailable back. Anything else continues. (#3769)
* Handle all errors for now. (#3781)
* Do not assume --yes was present when using pulumi in non-interactive mode (#3793)
* Upgrade all paths for sdk and pkg to v2
* Backport C# invoke classes and other recent gen changes (#4288)
Adjust C# generation
* Replace IDeployment with a sealed class (#4318)
Replace IDeployment with a sealed class
* .NET: default to args subtype rather than Args.Empty (#4320)
* Adding system namespace for Dotnet code gen
This is required for using Obsolute attributes for deprecations
```
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'ObsoleteAttribute' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'Obsolete' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
```
* Fix the nullability of config type properties in C# codegen (#4379)
- Ensure that type assertions are guarded, and that incorrectly-typed
properties return errors rather than panicking
- Expand the asset/archive tests in the Node SDK to ensure that eventual
archives and assets serialize and deserialize correctly
Fixes#2836.
Fixes#3016.
A resource can be imported by setting the `import` property in the
resource options bag when instantiating a resource. In order to
successfully import a resource, its desired configuration (i.e. its
inputs) must not differ from its actual configuration (i.e. its state)
as calculated by the resource's provider.
There are a few interesting state transitions hiding here when importing
a resource:
1. No prior resource exists in the checkpoint file. In this case, the
resource is simply imported.
2. An external resource exists in the checkpoint file. In this case, the
resource is imported and the old external state is discarded.
3. A non-external resource exists in the checkpoint file and its ID is
different from the ID to import. In this case, the new resource is
imported and the old resource is deleted.
4. A non-external resource exists in the checkpoint file, but the ID is
the same as the ID to import. In this case, the import ID is ignored
and the resource is treated as it would be in all cases except for
changes that would replace the resource. In that case, the step
generator issues an error that indicates that the import ID should be
removed: were we to move forward with the replace, the new state of
the stack would fall under case (3), which is almost certainly not
what the user intends.
Fixes#1662.
* NodeJS: allow callers to override provider version
* Python: allow callers to override provider version
* NodeJS: add version for invoke
* Python: add version to invoke
* NodeJS: add tests for ReadResource
* Post-merge cleanup
* update doc comments
Fixes#2277.
Adds a new ignoreChanges resource option that allows specifying a list of property names whose values will be ignored during updates. The property values will be used for Create, but will be ignored for purposes of updates, and as a result also cannot trigger replacements.
This is a feature of the Pulumi engine, not of the resource providers, so no new logic is needed in providers to support this feature. Instead, the engine simply replaces the values of input properties in the goal state with old inputs for properties marked as ignoreChanges.
Currently, only top level properties may be specified in ignoreChanges. In the future, this could be extended to support paths to nested properties (including into array elements) with a JSONPath/JMESPath syntax.
This update includes several changes to core `@pulumi/pulumi` constructs that will not play nicely
in side-by-side applications that pull in prior versions of this package. As such, we are rev'ing
the minor version of the package from 0.16 to 0.17. Recent version of `pulumi` will now detect,
and warn, if different versions of `@pulumi/pulumi` are loaded into the same application. If you
encounter this warning, it is recommended you move to versions of the `@pulumi/...` packages that
are compatible. i.e. keep everything on 0.16.x until you are ready to move everything to 0.17.x.
### Improvements
- `Output<T>` now 'lifts' property members from the value it wraps, simplifying common coding patterns. Note: this wrapping only happens for POJO values, not `Output<Resource>`s.
- Depending on a **Component** Resource will now depend on all other Resources parented by that
Resource. This will help out the programming model for Component Resources as your consumers can
just depend on a Component and have that automatically depend on all the child Resources created
by that Component. Note: this does not apply to a **Custom** resource. Depending on a
CustomResource will still only wait on that single resource being created, not any other Resources
that consider that CustomResource to be a parent.
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
This changes the input type for dependsOn from simply
`Resource[] | Resource` to `Input<Input<Resource>[]> | Input<Resource>`.
This permits `Output<Resource>`s, etc in addition to
`Promise<Resource>`s. The logic for dynamically unpicking the right
types and recursing through the data structures isn't straightforward,
but I've written a test for all of the interesting permutations.
This fixespulumi/pulumi#991.
* Protobuf changes
* Move management of root resource state to engine
This commit fixes a persistent side-by-side issue in the NodeJS SDK by
moving the management of root resource state to the engine. Doing so
adds two new endpoints to the Engine gRPC service: 1) GetRootResource
and 2) SetRootResource, which get and set the root resource
respectively.
* Rebase against master, regenerate proto
* Use Promise.resolve.
* Use `Inputs | Promise<Inputs> | Output<Inputs>` rather than
`Input<Inputs>`, which looks supremely bizarre.
* Update ComponentResource.registerOutputs also.
This change partly addresses pulumi/pulumi#1611, by permitting you
to export a promise at the top-level, and have it be recognized as
a stack output. In other words, you can now say things like
async function main() {
...
return {
a: "x",
...,
z: 42,
};
}
module.exports = main();
and your Pulumi program will record distinct outputs as you'd hope:
---outputs:---
a: "x"
...
z: 42
This is arguably just a bug in the way we implemented stack outputs.
The remainder of the requests in #1611 will remain open for future
design and discussion, as they have more subtle ramifications.
* Fix an issue with NodeJS host logging
Related to pulumi/pulumi#1694. This issue prevented the language host
from being aware that an engine (logging endpoint) was available and
thus no log messages were sent to the engine. By default, the language
host wrote them to standard out instead, which resulted in a pretty bad
error experience.
This commit fixes the PR and adds machinery to the NodeJS langhost tests
for testing the engine RPC endpoint. It is now possible to give a "log"
function to tests which will be hooked up to the "log" RPC endpoint
normally provided by the Pulumi engine.
* Remove accidental console.log