* Look for exact match when loading plugins
Pulumi's current behavior when loading plugins is surprising in that it
will attempt to load the "latest" provider binary instead of exactly the
version that was requested. Since provider binaries and provider
packages are tied together and versioned together, this is going to be
problematic if a provider makes a breaking change.
Although there are other issues in this area, this commit fixes the
arguably bug-like behavior of loading the latest plugin and instead opts
to load the plugin that exactly the requested semver range. Today, the
engine will never ask for anything other than an exact version match.
Since this is a breaking change, this commit also includes an
environment variable that allows users to return back to the "old"
plugin loading behavior if they are broken. The intention is that this
escape hatch can be removed in a future release once we are confident
that this change does not break people.
* CR feedback
* Use SelectCompatiblePlugin for HasPluginGTE check
* Revert "Make toString and toJSON internal (#2489)"
This reverts commit 7579b84f73.
* Revert "Update error message to point at docs. (#2488)"
This reverts commit 9156c26a2e.
* Revert "Throw on Output.toString and toJSON (#2486)"
This reverts commit c33b4505c0.
* Decrease log level for HTTP requests and responses
Logging each HTTP request and response can get quite chatty, especially
when publishing a lot of events. This increases the verbosity level of
these logs so that they don't get emitted at level 9, which is the
general level that providers use when issuing verbose logs.
* Appease linter
We previously logged the number of replaces and changes returned from a call to Diff, but not the actual properties that were forcing replace. Several times we've had to debug issues with unexpected replaces being proposed, and this information is very useful to have access to.
Changes the verbose logging to include the property names for both replaces and changes instead of just the count.
* Fix an issue with empty ID for CustomResource
The Python runtime was checking the ID field it receives from the engine
against None, assuming that the engine would not set the ID field if one
was not present. However, it does set the ID field; it is set to the
empty string when an ID is not known.
This commit fixes an issue that can cause certain IDs to be erroneously
considered to be known during previews, which can cause problems during
the Check phase of resources that directly reference IDs of other
resources.
* Add CHANGELOG
- Pick python as a base image. Debian build tools depend on 3.5, so don't fight that battle, just use an existing solution
- Fixes#2435
- Move the pulumi install to the bottom. Rule of thumb is you always install deps first then your software so you're not thrashing the dockerfile build because you only build images when your code changes, not when deps change.
- Do all of the dep work in one step and clean up. This makes the image have way fewer layers and makes the image a bit smaller
- Get consistent with repo addition. I'm not sure if this is the best way, but it's better.
- Add some failure handling to curl commands
- Avoid crazy ass curl-pipe-bash install scripts when possible in favor of crazy ass curl-pipe-apt-key 😨
- Add some github actions stuff in case people want to use this for actions. I'm here because the github action is wack, and I'm trying to align your dockerfiles across both repos.
* Enable delete parallelism for Python
* Add CHANGELOG.md entry
* Expand changelog message - upgrade to Python 3
* Rework stack rm test
The service now allows removing a stack if it just contains the top
level `pulumi:pulumi:Stack` resource, so we need to actually create
another resource before `stack rm` fails telling you to pass
`--force`.
Fixes#2444
When `pulumi stack rm` is run against a stack with resources, the
service will respond with an error if `--force` is not
passed. Previously we would just dump the contents of this error and
it looked something like:
`error: [400] Bad Request: Stack still has resources.`
We now handle this case more gracefully, showing our usual "this stack
still has resources" error like we would for the local backend.
Fixes#2431
We do all our work in a virtualenv and across repositories we now
consume dependencies via pypi (also installed in a virtualenv) so best
case install into the user site packages wastes time and maybe prints
some warnings and worse case it clobbers something they've installed
for real.
Today, we run 4 jobs for every push or PR build. Three Linux builds
which only differ by node version and an macOS build that also has a
different node version from the rest.
In practice this ends up generating a great deal of jobs during
development, given some of our workflows and these jobs often don't
find interesting issues.
We're going to start by relaxing things in the following ways:
- For a given PR, we'll just run a single Linux leg (as well as the
Windows leg we get from AppVeyor).
- For push jobs (which happen either when a PR is merged into master,
or a branch named `features/*` is pushed, we'll run a Linux leg and
and macOS leg (the macOS leg is run per push, so we build and
publish of the CLI for macOS builds)
- For our nightly cron job, we'll continue to run all three Linux
legs, to get coverage across different versions of nodejs.
If we end up seeing an uptick in regressions found by these jobs after
each commit, we can re-evaluate or pre checkin strategy.
In #2330 there was a case where if you didn't pass a value to the
`pulumi.Config()` constructor, things would fail in a weird manner.
This shouldn't be the case, and I'm unable to reproduce the issue. So
I'm updating the test to use the form that didn't work at one point so
we can lock in the win.
Fixes#2330
These changes add a new flag to the various `ResourceOptions` types that
indicates that a resource should be deleted before it is replaced, even
if the provider does not require this behavior. The usual
delete-before-replace cascade semantics apply.
Fixes#1620.