There are a few things happening here:
- Rename the command dispatch release events to be prefixed with trigger-
- Introduce a new command-dispatch event
This new event listens for a trigger term in a comment e.g. /run-acceptance-tests
This trigger term is *only* needed when the PR is from a fork! When the trigger term is posted
then the run-build-and-acceptance-tests.yml event is fired
- run-build-and-acceptance-tests.yml
If the user runs the code from a pulumi based branch, then the tests and builds will work as normal
If this file is being run via respository_dispatch then it will be able to run the test and builds
and also post a comment back to the PR with the link to the test run
It's important to say that PRs affecting the codegen and resource docs paths will only fire from a
pulumi based branch - there is currently no command dispatch events for these codegen and resource PRs!
* Properly resize arrays when adding
The current logic attempts to update the array but, because
append may need to allocate a new array with adequate space,
the code can currently leave dest referring to the old,
under-sized array. The solution is to use the set(dest)
logic that already exists and is used for the IsNull case.
Added a test case that would fail before this fix and now passes.
This fixespulumi/pulumi#5871.
* Add CHANGELOG entry
Fixes: #5452
When the user is requesting to change the secrets provider to a
passphrase provider, we now calculate that has been requested.
This means, we will prompt for a new passphrase for use in encrypting
the stack.
```
pulumi stack change-secrets-provider passphrase
Enter your passphrase to unlock config/secrets
(set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
Enter your new passphrase to protect config/secrets:
Re-enter your new passphrase to confirm:
Migrating old configuration and state to new secrets provider
Enter your passphrase to unlock config/secrets
(set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
```
Implement GetRequiredPlugins for Python, which determines the plugins
required by the program.
Also, if the `virtualenv` runtime option is set, and the specified
virtual directory is missing or empty, automatically create it and
install dependencies into it.
Running `pulumi` operations in parallel could occasionally result in truncating the `~/.pulumi/credentials.json` file and reading that truncated file from another process before the content could be written.
Instead, use `os.Rename` to atomically replace the file contents.
Concurrent `pulumi` operations could still compete for who gets to write the file first, and could lead to surprising results in some extreme cases. But we should not see the corrupted file contents any longer.
Fixes#3877.
Generate ResourcePackage and ResourceModule implementations and
registrations. A ResourcePackage is generated for any module that
includes a provider resource (which should be the root module only), and
a ResourceModule is generated for any module that includes a resource.
And add version info to Python registrations.
To de-risk the Pulumi v2.15.0 release, temporarily revert 679d40950f. Use of resource references will require `PULUMI_EXPERIMENTAL_RESOURCE_REFERENCES=1` to be set until the feature has been enabled by default.
* Correctly rename stack files during a rename
This fixespulumi/pulumi#4463, by renaming a stack's configuration
file based on its stack-part, and ignoring the owner-part. Our
workspace system doesn't recognize configuration files with fully
qualified names. That, by the way, causes problems if we have
multiple stacks in different organizations that share a stack-part.
The fix here is simple: propagate the new StackReference from the
Rename operation and rely on the backend's normalization to a
simple name, and then use that the same way we are using a
StackReference to determine the path for the origin stack.
An alternative fix is to recognize fully qualified config files,
however, there's a fair bit of cleanup we will be doing as part of
https://github.com/pulumi/pulumi/issues/2522 and
https://github.com/pulumi/pulumi/issues/4605, so figured it is best
to make this work the way the system expects first, and revisit it
as part of those overall workstreams. I also suspect we may want to
consider changing the default behavior here as part of
https://github.com/pulumi/pulumi/issues/5731.
Tests TBD; need some advice on how best to test this since it
only happens with our HTTP state backend -- all integration tests
appear to use the local filestate backend at the moment.
* Add a changelog entry for bug fix
* Add some stack rename tests
* Fix a typo
* Address CR feedback
* Make some logic clearer
Use "parsedName" instead of "qn", add a comment explaining why
we're doing this, and also explicitly ignore the error rather
than implicitly doing so with _.
Fixes: #5835
when rotating a key in the Azure KeyVault secrets provider, we had
the following error:
```
error: secrets (code=InvalidArgument): keyvault.BaseClient#Decrypt: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="BadParameter" Message="The parameter is incorrect.\r\n"
```
This was because we were not regenerating the EncrytpionKey when
we were changing the secrets provider. Therefore, we now ensure
that this key is regenerated and we can successfully change the secrets provider
```
▶ pulumi stack init dev --secrets-provider="azurekeyvault://stack72kv10.vault.azure.net/keys/pulumi-secret"
Created stack 'dev'
▶ pulumi config set MyDBRootPassword Password1234! --secret
▶ pulumi config --show-secrets
KEY VALUE
MyDBRootPassword Password1234!
▶ pulumi stack change-secrets-provider "azurekeyvault://stack72kv20.vault.azure.net/keys/pulumi-secret"
▶ pulumi config --show-secrets
KEY VALUE
MyDBRootPassword Password1234!
```
Generate ResourcePackage and ResourceModule implementations and
registrations. A ResourcePackage is generated for any module that
includes a provider resource (which should be the root module only), and
a ResourceModule is generated for any module that includes a resource.
Note that version information is currently omitted. We should fix this
up before enabling resource reference deserialization end-to-end.
There are two significant changes in this commit: one to the way
resource packages/modules are stored and retrieved, and one to resource
ref deserialization in the face of missing resource packages/modules.
Resource packages and modules no longer require an exact version match
during deserialization. Instead, the newest compatible version of the
package or module is selected. If no version was specified, the newest
version of the package or module will be chosen. As a special case, a
package or module that has no version will always be treated as the best
version for that package or module.
If a resource package or module is not found when attempting to
deserialize a resource reference, the SDK no longer emits an error, and
instead deserializes the reference as its URN or ID (if present). This
accommodates providers that have not yet been updated to include the
appropriate factory registrations.
- Differentiate between resource references that have no ID (i.e. because
the referenced resource is not a CustomResource) and resource references
that have IDs that are not known. This is necessary for proper
backwards-compatible serialization of resource references.
- Fix the key that stores a resource reference's package version in the
.NET, NodeJS, and Python SDKs.
- Ensure that the resource monitor's marshalling/unmarshalling of inputs
and outputs to/from calls to `Construct` retain resource references as
appropriate.
- Fix serialization behavior for resources -> resource references in the
Go SDK: if a resource's ID is unknown, it should still be serialized
as a resource reference, albeit a reference with an unknown ID.
