<!---
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. -->
This change removes the SxS check in the Node.js Automation API since
it's blocking a customer scenario and isn't needed anymore now that
#5449 has been addressed with #10568.
The check was originally added in #7349 to provide a helpful error
message when multiple versions of `@pulumi/pulumi` were used with inline
programs, which could cause clashes with global state. Since then, we've
changed how state is stored to allow parallel execution of multiple
inline programs with #10568. However, the SxS checks were not removed as
part of that change.
A customer recently hit the error associated with the SxS check. They
are creating a Next.js program that runs Pulumi operations as inline
programs. Next.js ends up loading modules multiple times in a way that
confuses the SxS checker, causing the error to be thrown, even though it
wouldn't have been a problem.
Fixes#14128
We should support all features in mocks that we are supporting
otherwise. We did a similar thing in pulumi-dotnet:
https://github.com/pulumi/pulumi-dotnet/pull/93.
However here we're not simply changing hasSupport to true.
1e09626bc7
has a good explanation of why we only support specific values here.
However really we only need to disable support for `outputValues`, and
that only if output values are disabled. Originally this was true if
`PULUMI_ENABLE_OUTPUT_VALUES` was set, but that environment variable was
later inverted: 3027d01f25.
This ended up being a little bit more complicated than just passing
true, but I think it's more correct this way. I'm also happy to change
it back to just passing through `true` if that's preferred. Once we
decided on whether this is the right way to do it vs. just passing
`true` unconditionally I'll also update `java` and `dotnet` (if we're
going this way) to do the same.
Fixes#13355
## 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
- [ ] 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. -->
# Description
When using closure serialization, we lookup `package.json` inside of the
current working directory `.`. However, if users put their
`package.json` file in a parent directory and their pulumi program in a
child directory, then it can't find `package.json` and fails to create
inline lambdas.
This PR addresses the issue by looking up `package.json` starting from
the current working directory recursively up parent directories until it
finds the closest `package.json` file and uses that as the "root" of the
project from which the dependencies are inferred.
Fixes#13764
Didn't know how to write an integration test for this since the issue is
using pulumi/aws but locally testing these code changes succeed the
program.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] 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. -->
---------
Co-authored-by: Fraser Waters <fraser@pulumi.com>
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).
13070: fix uncatchable `Resource monitor is terminating` r=abhinav a=dixler
<!---
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 https://github.com/pulumi/pulumi/issues/10744Fixes#12970
Allows users to catch `Resource monitor is terminating` exceptions from automation API.
When using Node automation API, and `registerResource()` fails due to the resource monitor shutting down, an uncaught rejection is thrown by a `debuggablePromise` and causes the process to exit without allowing users to handle the exception.
## 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. -->
Co-authored-by: Kyle Dixler <kyle@pulumi.com>
A failed update can lead to an unavailable resource monitor creating an
uncaught rejected promise which makes Automation API exit prematurely
since the exception was uncatchable. Prints the error message to stderr
only once to avoid spamming the user.
Fixes#10744Fixes#12970
This change updates the engine to detect if a `RegisterResource` request
is coming from an older Node.js SDK that is using incorrect alias specs
and, if so, transforms the aliases to be correct. This allows us to
maintain compatibility for users who have upgraded their CLI but are
still using an older version of the Node.js SDK with incorrect alias
specs.
We detect if the request is from a Node.js SDK by looking at the gRPC
request's metadata headers, specifically looking at the "pulumi-runtime"
and "user-agent" headers.
First, if the request has a "pulumi-runtime" header with a value of
"nodejs", we know it's coming from the Node.js plugin. The Node.js
language plugin proxies gRPC calls from the Node.js SDK to the resource
monitor and the proxy now sets the "pulumi-runtime" header to "nodejs"
for `RegisterResource` calls.
Second, if the request has a "user-agent" header that starts with
"grpc-node-js/", we know it's coming from the Node.js SDK. This is the
case for inline programs in the automation API, which connects directly
to the resource monitor, rather than going through the language plugin's
proxy.
We can't just look at "user-agent", because in the proxy case it will
have a Go-specific "user-agent".
Updated Node.js SDKs set a new `aliasSpecs` field on the
`RegisterResource` request, which indicates that the alias specs are
correct, and no transforms are needed.
The Node.js SDK is not sending the right `Parent` and `NoParent` alias
spec.
117955ce14/sdk/nodejs/runtime/resource.ts (L332-L361)
- It does not set `NoParent` when it should, but instead sets `Parent`
to empty.
- It sets `NoParent` to true and leaves `Parent` empty when both the
alias and resource have no `Parent` specified.
- If the resource has a parent and `Parent` isn't set on the alias, it
sends the parent's URN for the `Parent`.
This commit fixes these issues so that the Node.js SDK sends correctly
specified alias specs.
However, we continue to set the alias's `Parent` to the resource's
parent if the alias does not specify a `Parent`. We shouldn't have to do
this, but doing it allows us to maintain backwards compatibility in the
case when the Node.js SDK is upgraded, but not the CLI.
This change refactors assignment statements used as expressions
to prefer assignment statements instead. Assignments are often
assumed to now evaluate to a value, but instead to represent a
change to a lexical binding. By using them as expressions, we can
write confusing and buggy code. This commit eliminates those instances,
and enables a lint to prevent future occurances.
Empty interfaces have no effect, even when they are subtyping
other interfaces. An empty interface is always equivalent to its supertype.
They can be safely replaced with type aliases, which better express
the semantic equivalence between the two types.
The non-null assertion operator ("!") has no effect
if applied twice. !! as a postfix operation does nothing.
This commit eliminates usage of that syntactic form.
This commit removes instances of prefix-!! where the value
would already be coerced into a boolean. It also removes
instances where the "optional chaining" operator (?.)
would suffice.
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
We added a warning here with the intention of turning it into an error
in July 2022, but we never did.
While we're discussing whether we still want this to become an error,
drop the specific date and just refer to "a future version."
Refs #8799
NodeJS equivalent of the StackReference.GetOutputDetails
method and accompanying type added to the Go SDK in #12034.
This will allow users of the TypeScript and JavaScript SDKs
to fetch outputs from stack references directly--without going through
an Output type.
Couple notes about testing:
- `MockMonitor.readResource` kept exploding because the getCustom method
was missing on the provided object.
I didn't find any examples in the Node SDK
of using mocks to test StackReferences,
so I'm guessing this was an unexercised code path.
I've fixed that.
- It seems that the JavaScript SDK promotes an entire map to secret
if an item inside it is a secret.
So I had to isolate the two test cases into separate outputs
to get the plain text case to be written as a "value".
If there's a more correct way of setting up that mock,
I'm happy to merge the outputs back into a single map
for a more representative test case.
Refs #10839, #5035
This change fixes the `DeletedWith` resource option in the Go, Node.js,
and Python SDKs and adds tests.
This feature was a community contribution and while there were engine
tests included with the original PR, there weren't any tests confirming
the functionality worked correctly from each SDK.
Here's a summary of the fixes:
* Go: The `DeletedWith` resource option was never usable as it accepted
a URN instead of a Resource. We discussed this internally a while back
and decided to go ahead and fix this. (Note: While changing the
signature is technically a breaking change, the feature is currently
unusable, so the change would not break anyone, so there's no need to
wait for a major version bump.)
* Node.js: The `deletedWith` resource option did not work at all from
the Node.js SDK because it was incorrectly passing the resource object
itself in the RegisterResource request, rather than the resource's
URN.
* Python: The `deleted_with` resource option did not work at all from
the Python SDK because it was incorrectly passing the resource object
itself in the RegisterResource request, rather than the resource's
URN.
A `FailsOnDelete` resource has been added to the testprovider, which
will fail when its `Delete` gRPC is called. The tests use this to ensure
`Delete` is not called for resources of this type with the `DeletedWith`
option specified.
11481: Closure emit requires in global scope, to have them run in Lambda init phase r=RobbieMcKinstry a=pjoe
<!---
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
Emit `require` for importing modules in global scope.
This allows these to run during the init phase of AWS Lambda, where more CPU is available, resulting in greatly imrpoved cold start performance (often 5x or more).
Fixes#11468
## Checklist
<!--- 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Pelle Johnsen <pelle.johnsen@gmail.com>
https://github.com/pulumi/pulumi/pull/11093 changed the Node.js SDK to pass a provider specified in a MLC's `ResourceOptions.provider` to the engine.
Unfortunately, this regresses behavior that existing programs rely on. For example:
```ts
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";
const myRegion = new aws.Provider("us-east-1", {
region: "us-east-1",
});
const vpc = new awsx.ec2.Vpc("awsx-nodejs-default-args", {}, { provider: myRegion });
```
In the above program, an explicit _aws_ provider is being passed to the _awsx_ `VPC` component, with the intention that the _aws_ provider will be used as the provider for all of `Vpc`'s children.
With the change in https://github.com/pulumi/pulumi/pull/11093, the engine would try to call `Construct` for the `Vpc` using the specified `aws` provider, which does not work (it fails with `plugins that can construct components must support secrets`).
This change reverts the change from https://github.com/pulumi/pulumi/pull/11093 that included the `provider` in the `RegisterResourceRequest` for MLCs, and adds a regression test to lock-in the previous behavior.
Note: We do want to be able to support specifying a MLC's provider (to allow explicit providers for MLCs), but we'll address that in a separate change.
We used to always keep resource references when marshaling the results of `pulumi:pulumi:getResource`, but this regressed in #9323 to only keep resource if request's `acceptResources` flag was set. Unfortunately, that flag was not being set when calling `pulumi:pulumi:getResource` in the Go, Node.js, and Python SDKs (although, it was being set for .NET).
Two fixes:
1. Update the monitor to go back to always keeping resources when `pulumi:pulumi:getResource` is being invoked. This way, older SDKs that are not setting `acceptResources` will go back to the original behavior.
2. Update the SDKs to always set `acceptResources`, so that these newer versions of the SDKs will work with older engines that are checking `acceptResources`.
(2) will help us with EKS 1.0. We'll be able to update EKS to use a version of `@pulumi/pulumi` with the fix to set the `acceptResources` flag.
In many cases there is no need to delete resources if the container
resource is going to be deleted as well.
A few examples:
* Database object (roles, tables) when database is being deleted
* Cloud IAM bindings when user itself is being deleted
This helps with:
* Speeding the deletion process
* Removing unnecessary calls to providers
* Avoiding failed deletions when the pulumi user running the
plan has access to the container resource but not the contained
ones
To avoid deleting contained resources, set the `DeletedWith` resource
option to the container resource.
TODO:
Should we support DeletedWith with PendingDeletes?
Special case might be when the contained resource is marked as pending
deletion but we now want to delete the container resource, so
ultimately there is no need to delete the contained anymore
This is approach needs to occur in `resmon` since `*resmon` dispatches
`Construct` calls directly.
TS: Send providers map for all components
Ensure that `providers` is passed in all SDKs
The .NET SDK already does the right thing
Add golang integration test
Add local dependency
Fix test
Use new test
Get test working
Fix nits
10820: Make getOrganization total, default to 'organization' r=AaronFriel a=Frassle
<!---
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
Changes `getOrganization` to return "organization" by default. This will apply when using filestate, or by default in unit tests (unless explicitly set as part of test setup).
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
## Checklist
<!--- 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
10833: Fix regression validating project files with `refresh: always` set r=justinvp a=justinvp
We recently started validating the `Pulumi.yaml` file against its schema, leading to the following error when the `refresh: always` option is specified:
```
error: could not load current project: 1 error occurred:
* #/options/refresh: expected boolean, but got string
```
The problem is the feature is expecting a string value of `"always"` but the schema for the project file is incorrectly specified as `boolean`.
This change fixes the schema, which avoids the error. A separate change will fix the documentation at https://www.pulumi.com/docs/reference/pulumi-yaml/#options-optionsFixes#10824
Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
10622: Enable ESModule interoperability r=RobbieMcKinstry a=RobbieMcKinstry
<!---
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
This PR enables ESModule interop for the NodeJS SDK. By enabling interop, we should in theory remove subtle bugs from Pulumi programs that assume our libraries are interopable. In practice, only a few modules weren't already interoperable. Nevertheless, enabling this compiler flag will require future code to be compatible with ESModules, potentially eliminating future bugs.
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
Fixes https://github.com/pulumi/pulumi/issues/10621
This PR is required for bundling the NodeJS runtime (https://github.com/pulumi/pulumi/issues/10210).
## Checklist
<!--- 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 updated the [CHANGELOG-PENDING](https://github.com/pulumi/pulumi/blob/master/CHANGELOG_PENDING.md) file with my change
<!--
If the change(s) in this PR is a modification of an existing call to the Pulumi Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Robbie McKinstry <robbie@pulumi.com>
10806: [sdk/nodejs] Mark internal APIs `@internal` to filter from SDK docs r=justinvp a=justinvp
These exported APIs aren't intended for public use. Marking them as ``@internal`` makes TypeScript remove them from the `.d.ts` files and removes them from our SDK docs.
10810: Update automation api secrets provider docstring link r=Frassle a=mrod-io
<!---
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.
-->
Updates an outdated docstring link I stumbled across while using Pulumi Automation API.
There is no existing issue.
This is a non-code change and I believe it could be labeled `impact/no-changelog-required`; as such I have not made Changelog updates as per the [updated guidelines](385d08218a). If I am mistaken please let me know!
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
## Checklist
<!--- 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.
-->
- [ ] 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Co-authored-by: Matthew Rodrigues <matthew.rodrigues@starburstdata.com>
These exported APIs aren't intended for public use. Marking them as `@internal` makes TypeScript remove them from the `.d.ts` files and removes them from our Node.js SDK docs.