As part of our continued effort to make our releases more useful,
we will be adding our CHANGELOG entries to the GitHub Release.
To make this process smooth, we are going to change things a little:
1. All new changelog entries when submitting a PR for an upcoming
release will now need to get added to CHANGELOG_PENDING.md
This is the source of information for what will be delivered in the
release.
2. When a release is being made, the entries from CHANGELOG_PENDING
will be copied to a new version and dated section in CHANGLOG to
mark the release
3. The GH tags will continue as normal and Goreleaser will copy
the changelog entries to the release section in GH
We currently include `version.txt` in the package via `<Content Include="version.txt">`. This places the file in the NuGet package in two locations: the `content` directory and `contentFiles`.
We want the file to be in `content` because this is where the Pulumi .NET Language host looks for the file when determining a program's required plugins.
However, having the file in `contentFiles` is problematic. For packages that reference other Pulumi resource packages (e.g. for multi-lang components), referenced `contentFiles` are included in the package by default. This means another package's `version.txt` will be included and used over the current project's `version.txt`. For example, if a multi-lang component package `Pulumi.Xyz` references `Pulumi.Aws`, the `version.txt` from `Pulumi.Aws` will be used in `Pulumi.Xyz` package rather than the intended `version.txt` for `Pulumi.Xyz`.
To address this, stop including `version.txt` in `contentFiles`. We do this by changing the `<Content Include="version.txt" />` to `<None Include="version.txt" Pack="True" PackagePath="content" />` in the project file. This ensures the file will still be included in the package in the `content` dir (where the Pulumi .NET language host expects to find it), but doesn't include the file in `contentFiles` which would cause it to be used in other packages that reference the package.
Further, when generating `<PackageReference>`s for packages that start with "Pulumi.", include an additional `ExcludeAssets="contentFiles"` attribute to prevent the package's `contentFiles` from being included.
Fixes: #4029Fixes: #3537
Should the user want to get permalinks when using a self-managed backend, they can pass a flag:
```
$ pulumi up --suppress-permalink false
```
Permalinks for these self-managed backends will be suppressed on `update`, `preview`, `destroy`,
`import` and `refresh` operations.
It is possible for the same version of the same provider SDK to be loaded multiple times in Node.js. In this case, we might legitimately get mutliple registrations of the same resource. It should not matter which we use, so we can just skip re-registering. De-serialized resources will always be instances of classes from the first registered package.
Example layout this addresses. Registrations of resources in `package3` at the same verrsion.
`node_modules`
`@pulumi/pulumi`
`package1`
`node_modules`
`package3`
`package2`
`node_modules`
`package3`
Fixes#6258.
This new optional file can be used to include additional metadata about the provider plugin (such as version and custom server URL), which the Python language host will use when determining a program's required plugins.
This change fixes the codegen to emit the file in the correct location (inside the package dir). Note: Providers need to opt-in to emitting this file via a schema option (because it requires some Makefile changes to insert the version in the file) and we haven't done that with any of our providers yet.
* Init Workspace interface for C# Automation API
* fleshing out workspace interface and beginning of local workspace implementation
* initial run pulumi cmd implementation
* resolve issue with pulumi cmd cleanup wrapper task after testing
* flesh out local workspace implementation, flesh out stack implementation, cleanup run pulumi cmd implementation and make it an instance so it is mockable/testable, separate serialization in prep for custom converters
* project settings json serialization implemented
* Initial commit of language server
* Add deployment from language server
* Cleanup
* finish json serialization
* project runtime yaml serialization completed. just need stack config value yaml serialization
* Remove typed argument
* Limit concurrency
* Rename file for consistency
* final commit of a semi-working project settings & stack settings serialization so that it is in the commit history
* modify workspace API so that settings accessors aren't fully exposed since we are defering a complete serialization implementation until a later date
* yaml converters wrap any outgoing exceptions so resolve that
* getting the beginning of inline program GRPC communication set up
* stack lifecycle operations implemented, and switched to newtonsoft for JSON serialization
* change back to system.text.json with a custom object converter
* local workspace tests written, working on getting them passing
* fix the encoding on the GO files used for testing
* all tests passing except inline program, pulumi engine not available with inline
* inline program engine is now running as expecting, but inline program is not recognizing local stack config
* All tests passing, but no concurrency capability because of the singleton DeploymentInstance.
* cleanup unnecessary usings
* minor cleanup / changes after a quick review. Make sure ConfigureAwait is used where needed. Remove newtonsoft dependency from testing. Update workspace API to use existing PluginKind enum. Modify LanguageRuntimeService so that its semaphore operates process-wide.
* support for parallel execution of inline program, test included
* Update LocalWorkspaceTests.cs
remove some redundancy from the inline program parallel execution text
* flesh out some comments and make asynclocal instance readonly
* Strip out instance locking since it is no longer necessary with AsyncLocal wrapping the Deployment.Instance. Modify CreateRunner method such that we are ensuring there isn't a chance of delayed synchronous execution polluting the value of Deployment.Instance across calls to Deployment.RunAsync
* resolve conflicts with changes made to Deployment.TestAsync entrypoints
* update changelog
* write a test that fails if the CreateRunnerAndRunAsync method on Deployment is not marked async and fix test project data file ref
* make resource package state share the lifetime of the deployment so that their isn't cross deployment issues with resource packages, add support and tests for external resource packages (resource packages that aren't referenced by the executing assembly)
* enable parallel test collection execution in test suite, add some additional tests for deployment instance protection and ensuring that our first class stack exceptions are thrown when expected
* minor inline project name arg change, and re-add xunit json to build output (whoops)
* strip out concurrency changes since they are now in #6139, split automation into separate assembly, split automation tests into separate assembly
* add copyright to the top of each new file
* resolve some PR remarks
* inline program exception is now properly propagated to the caller on UpAsync and PreviewAsync
* modify PulumiFn to allow TStack and other delegate overloads without needing multiple first class delegates.
* whoops missing a copyright
* resolve getting TStack into IRunner so that outputs are registered correctly and so that there isn't 2 instances of Pulumi.Stack instantiated.
* resolve issue with propagation of TStack exceptions and add a test
* add support for a TStack PulumiFn resolved via IServiceProvider
* update automation API description
* fix comment and remove unnecessary TODOs
* disable packaging of automation api assembly
* re-name automation api documentation file appropriately
* add --limit support to dotnet automation api for stack history per #6257
* re-name XStack as WorkspaceStack
* replace --limit usage with --page-size and --page in dotnet automation api per #6292
Co-authored-by: evanboyle <evan@pulumi.com>
Co-authored-by: Josh Studt <josh.studt@figmarketing.com>
Co-authored-by: Dan Friedman <dan@thefriedmans.org>
Co-authored-by: David Ferretti <David.Ferretti@figmarketing.com>
Co-authored-by: Mikhail Shilkov <github@mikhail.io>
The schema specifies supported environment variables
for Provider inputs, but these are not currently reflected
in the generated docs. This change adds any supported
environment variables to the input property comment
field on Provider resources.
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
This way, the tests use the built-in virtual environment support by
default, which is what most customers will be using. A new `UsePipenv`
option is available to go back to using pipenv for tests.
We previously looked for `python3` and fallback to `python` on all systems. However, our Windows CI images include a `python3.exe` symlink to `python.exe` which does not work with `venv`. So on Windows, just look for `python` first, falling back to `python3`. (The default python.org Windows installation only includes `python.exe`).
