This name better suits the semantics of the type, and aligns with the
rename of deploy.Plan to deploy.Deployment. These changes also refactor
the `update` method s.t. previews and updates are more consistent in
their behavior (e.g. duration and resource changes are now reported for
both, incl. on error paths).
Rename deploy.Plan to deploy.Deployment.
There are two benefits to this change:
1. The name "Deployment" more accurately reflects the behavior of the
type, which is responsible for previewing or executing a deployment.
2. Renaming this type frees up the name "Plan" for use when addressing
#2318.
Fixes: #5626
It used to be:
```
Policy Violations:
[advisory] aws v0.1.20200912 allowed-image-owner (demo-aws-ts-webserver-server-0: aws:ec2/instance:Instance)
Check machine image is from an approved publisher.
Publisher [137112412989] is not one of [self,099720109477].
```
Notice that it was name: type
We would rather this was type: name
```
Policy Violations:
[advisory] aws v0.1.20200912 allowed-image-owner (aws:ec2/instance:Instance: demo-aws-ts-webserver-server-0)
Check machine image is from an approved publisher.
Publisher [137112412989] is not one of [self,099720109477].
```
The way `pulumi new` installs dependencies for .NET projects is slightly different from other languages. For Node.js, Python, and Go, `pulumi new` runs the appropriate command to install project dependencies (e.g. `npm install`, `pip install`, or `go mod download`). For .NET, it calls the same routine used during `preview|up` to ensure required plugins are installed. For .NET, this ends up running `dotnet build` which implicitly installs Nuget packages, builds the project, and also attempts to determine and install the needed Pulumi plugins. When this operation runs during `preview|up`, and there are failures installing a plugin, the error is logged, but deliberately not returned, because an error will be shown for missing plugins later on during the `preview|up` operation. However, during `pulumi new`, we should show any plugin install errors.
When installing a plugin, previous versions of Pulumi extracted the
plugin tarball to a temp directory and then renamed the temp directory
to the final plugin directory. This was done to prevent concurrent
installs: if a process fails to rename the temp dir because the final
dir already exists, it means another process already installed the
plugin. Unfortunately, on Windows the rename operation often fails due
to aggressive virus scanners opening files in the temp dir.
In order to provide reliable plugin installs on Windows, we now extract
the tarball directly into the final directory, and use file locks to
prevent concurrent installs from toppling over one another.
During install, a lock file is created in the plugin cache directory
with the same name as the plugin's final directory but suffixed with
`.lock`. The process that obtains the lock is responsible for extracting
the tarball. Before it does that, it cleans up any previous temp
directories of failed installs of previous versions of Pulumi. Then it
creates an empty `.partial` file next to the `.lock` file. The
`.partial` file indicates an installation is in-progress. The `.partial`
file is deleted when installation is complete, indicating the plugin was
successfully installed. If a failure occurs during installation, the
`.partial` file will remain indicating the plugin wasn't fully
installed. The next time the plugin is installed, the old installation
directory will be removed and replaced with a fresh install.
This is the same approach Go uses for installing modules in its
module cache.
Just what it says on the tin. This is implemented by changing the
`GetPackageConfig` method of `ConfigSource` to return a `PropertyMap`
and ensuring that any secret config is represented by a `Secret`.
