Commit Graph

74 Commits

Author SHA1 Message Date
Julien 29124c92bd
Wait for resources in the input property dependencies ()
Besides the explicitly provided resources from the `dependsOn` option,
we need to also take into account the resource dependencies from the
invoke’s arguments.
2025-01-10 18:38:39 +00:00
Julien 95e3d8fe26
Avoid calling invokes with dependencies on unknown resources ()
Nodejs implementation of 

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],
})
```
2025-01-07 09:55:27 +00:00
Thomas Gummerer 12d8351f91
set mock monitor in global store ()
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
2024-11-21 09:39:37 +00:00
Julien cfd7ce00ef
[Node.js] Allow specifiying dependencies for output invokes ()
Provider functions that take inputs as arguments, and return an output
(aka output invokes), now allow specifying a `dependsOn` option. This
allows programs to ensure that invokes are executed after things they
depend on, similar to the [`depdendsOn` resource
option](https://www.pulumi.com/docs/iac/concepts/options/dependson/).

This is based on https://github.com/pulumi/pulumi/pull/16560 which was
reverted in https://github.com/pulumi/pulumi/pull/16642. Unlike the
previous PR, this only adds the `dependsOn` option to output invokes
(those that return an output, and use SDK invokeOutput function
internally).

https://github.com/pulumi/pulumi/discussions/17710

Fixes https://github.com/pulumi/pulumi/issues/17748
2024-11-20 16:03:11 +00:00
Julien a3c0ea5455
Add NodeJS test for parameterized providers ()
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>
2024-08-09 08:34:29 +00:00
Justin Van Patten 5d6e340c10
[sdk/nodejs] Save pkg/mod registrations on async local store ()
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 

---------

Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
2024-08-02 07:37:06 +00:00
Will Jones 100470d2e7
Revert "Implement `dependsOn` for invokes in the NodeJS SDK ()" ()
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.
2024-07-12 10:16:55 +00:00
Will Jones 492c57c7dd
Implement `dependsOn` for invokes in the NodeJS SDK ()
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 
2024-07-03 14:47:59 +00:00
Will Jones d64448ec3b
Replace Rome with Biome in the NodeJS SDK ()
As @denbezrukov notes in , 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 

Co-authored-by: Denis Bezrukov <6227442+denbezrukov@users.noreply.github.com>
2024-06-24 11:14:56 +00:00
Kyle Dixler 3d14952860
NodeJS now accepts unknown resource IDs for read resource ()
<!--- 
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  

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. -->
2023-10-19 16:00:10 +00:00
Pat Gavlin 248f78bafe [sdk/*] Add support for resource source positions
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).
2023-07-13 16:46:04 -07:00
Justin Van Patten db1d8c7217 [sdk/nodejs] Update langhost test for packaged component providers
Update the test for the behavior we expect. Currently fails.
2023-07-13 07:16:56 -07:00
Robbie McKinstry e05a3bd81c
Apply autoformat
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.
2023-04-28 18:27:10 -04:00
Justin Van Patten 9e73c75cd6 [sdk/nodejs] Fix hang due to component children cycles
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
2023-04-07 07:34:38 -07:00
Kyle Pitzen 92cb70996c feat(sdk/nodejs): delegates alias computation to the engine 2022-12-15 17:23:31 -05:00
Kyle Pitzen ae346aa33c chore(sdk/nodejs): Adds tests for resource alias combinations 2022-09-16 14:18:59 -04:00
Kyle Pitzen c4c46c3222
fix(ux): Adds a warning message when module resolution is ambiguous ()
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
2022-08-16 14:41:15 -04:00
Fraser Waters 0d0144bca2
Stop using Get/SetRootResource in nodejs ()
* 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
2022-06-30 11:04:49 +01:00
Ian Wahbe b783928bd3
[sdk/nodejs] Pickup provider as part of providers ()
* [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
2022-02-04 12:38:34 +01:00
Lewis Liu b640c8dd7b
Support native ES module for node sdk ()
This PR makes the minimum set of changes possible to support native ES modules in the Pulumi Node SDK.
2021-12-29 19:22:01 -08:00
Luke Hoban eb32039013
Add `replaceOnChanges` resource option ()
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 .

Co-authored-by: Levi Blackstone <levi@pulumi.com>
2021-07-01 13:32:08 -06:00
Komal 6949101428
Replace equal and deepEqual with strictEqual and deepStrictEqual () 2020-10-21 10:21:47 -07:00
komal 28d69e963e add tests for node and python 2020-04-23 11:16:36 -07:00
CyrusNajmabadi 66bd3f4aa8
Breaking changes due to Feature 2.0 work
* Make `async:true` the default for `invoke` calls ()

* Switch away from native grpc impl. ()

* Remove usage of the 'deasync' library from @pulumi/pulumi. ()

* Only retry as long as we get unavailable back.  Anything else continues. ()

* Handle all errors for now. ()


* Do not assume --yes was present when using pulumi in non-interactive mode ()

* Upgrade all paths for sdk and pkg to v2

* Backport C# invoke classes and other recent gen changes ()

Adjust C# generation

* Replace IDeployment with a sealed class ()

Replace IDeployment with a sealed class

* .NET: default to args subtype rather than Args.Empty ()

* 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 ()
2020-04-14 09:30:25 +01:00
CyrusNajmabadi 342b80b768
Add a supported api for components to indicate that they are asynchronously constructed. () 2019-12-17 15:34:30 -08:00
CyrusNajmabadi 714e5628cc
Add test to validate that lifted properties on output-wrapped Resources. () 2019-12-10 00:40:28 -08:00
CyrusNajmabadi 048acc24f7
Allow users to export a top-level function to serve as the entrypoint to their pulumi app. () 2019-12-09 11:28:20 -08:00
Pat Gavlin 91ff3d9434
Skip tests that hang on Node 12.11.x+ ()
Fixes .
2019-11-19 18:48:27 -08:00
CyrusNajmabadi 91addf2feb
New approach to move us to using `deasync` as little as possible (and with as little impact to users as possible). () 2019-10-14 22:08:06 -07:00
CyrusNajmabadi 376d28318f
Properly handle recursive outputs without penalizing non-recursive ones. () 2019-09-10 12:29:52 -07:00
Pat Gavlin 62189e6053
Harden asset and archive deserialization. ()
- 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 .
Fixes .
2019-08-06 16:32:05 -07:00
Pat Gavlin e1a52693dc
Add support for importing existing resources. ()
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 .
2019-07-12 11:12:01 -07:00
CyrusNajmabadi 54cbda80c1
Store information about a CustomResource's provider in __providers. () 2019-06-11 16:57:37 -07:00
CyrusNajmabadi 55bb3b2486
Simplify API for passing providers to a ComponentResource. () 2019-06-06 16:20:12 -07:00
Matt Ellis 9325b6ec61 Add logging to tests 2019-05-01 10:04:27 -07:00
Sean Gillespie ad32d9d8ac
Plumb provider version through language hosts to engine ()
* 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
2019-04-23 11:02:51 -07:00
Luke Hoban 0550f71a35
Add an ignoreChanges resource option ()
Fixes .

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.
2019-04-22 13:54:48 -07:00
CyrusNajmabadi 1f51ec00fc
Revert 'Simplify API for passing providers to a ComponentResource ()' () 2019-03-28 18:31:03 -07:00
CyrusNajmabadi 49a8e73aa7
Ensure that the values in 'dependsOn' are actually Resources. () 2019-03-28 17:27:51 -07:00
CyrusNajmabadi 7193622183
Simplify API for passing providers to a ComponentResource () 2019-03-28 15:04:07 -07:00
CyrusNajmabadi c6d87157d9
Use result.Result in more places. () 2019-03-19 16:21:50 -07:00
CyrusNajmabadi 7f5e089f04
Update `@pulumi/pulumi` to version 0.17.0 ()
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.
2019-03-05 17:06:57 -08:00
CyrusNajmabadi 93defd4b90
Rollback waiting on children of a component when waiting on the component. () 2019-02-27 12:41:44 -08:00
CyrusNajmabadi c53f697a6f
Fix deadlock when waiting for transitive dependencies () 2019-02-24 12:14:16 -08:00
Pat Gavlin 1ecdc83a33 Implement more precise delete-before-replace semantics. ()
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.
2019-01-28 09:46:30 -08:00
Joe Duffy a337fd7379
Permit dependsOn that are Outputs (of Outputs) ()
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 fixes .
2018-11-19 11:22:55 -05:00
Sean Gillespie 2d4a3f7a6a
Move management of root resource state to engine ()
* 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
2018-09-18 11:47:34 -07:00
joeduffy 70e1dbfe19 Incorporate PR feedback
* Use Promise.resolve.

* Use `Inputs | Promise<Inputs> | Output<Inputs>` rather than
  `Input<Inputs>`, which looks supremely bizarre.

* Update ComponentResource.registerOutputs also.
2018-09-02 12:15:58 -07:00
joeduffy 44c17e4877 Allow promise exports
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  will remain open for future
design and discussion, as they have more subtle ramifications.
2018-09-02 10:41:04 -07:00
Sean Gillespie a0cf415179
Fix an issue with NodeJS host logging ()
* Fix an issue with NodeJS host logging

Related to . 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
2018-08-24 16:50:09 -07:00