Previously, we would compute a version for a build by taking the last
relaesed bversion and then increment the patch number. We did this
because during pre 1.0 milestones, we would use the minor version to
say that there had been a "breaking change" and use the patch version
to mean there had been fixes or new features.
For packages that are 1.0 or later, we are now going to bump the minor
version per release and will use the patch version just for cases
where we do one off hot fixes.
This change updates our version generation logic to be in line with
this new plan.
Adds test coverage for cloud-backed secrets combined with filestate backend. This combination (for example, S3 + KMS) is likely to be common.
Fixes#3189.
Fixes: #2319
In #2319, a user is hitting the gRPC limit on the message size the
server can receive when uploading ec2 user-data
This commit doubles the limit that can be sent from `1024*1024*4` to
`1024*1024*8`
We had been using `pandoc` to convert our README.md into a README.rst
for use with `setup.py` and the python package ecosystem. It turns out
that we can use markdown if we set a content type. So let's do that
and make things a little simpler.
While I was in the area, I made the encoding of UTF-8 explicit when
opening README.md.
This matches the behavior of the display logic, which does not consider
reads to be changes. This also matches the expectation of tests that
pass `--expect-no-changes` (and likely user intuition).
The code forced the secret backend to be passphrase when using a
`filestate.Backend`, which means you can't use GCP/AWS/Azure KMS with
a cloud bucket state storage.
This PR removes that check and only forces passphrase storage when
explicitly set.
* Add the ability to log all engine events to a file.
The path to the file can be specified using the `--event-log` flag to
the CLI. The file will be truncated if it exists. Events are written as
a list of JSON values using the schema described by `pkg/apitype`.
* Expose update engine events to ExtraRuntimeValidation.
Just what it says on the tin. Events from previews are not exposed.
- Do not use a non-zero-to-zero transition in the number of outstanding
RPCs to determine the completion of a Python program until after the
synchronous piece of the program has finished running is complete
- Instead of using a future to indicate that either a) a zero-to-one
transition in the number of outstanding RPCs has occurred, or b) an
unhandled exception has occurred, a) observe the transition itself,
and b) use an optional exception field to track the presence or
absence of an exception.
Fixes#3162.
When installing plugins, we download the plugin into a temporary
folder, unpack it and then move that folder into its final
location (as an atomic operation). We do this so that if the download
fails in some way, we would not "poision" our plugin cache.
In order to ensure the move into the final location happens
atomically, we download the plugin into a folder with a `.tmpXXXXXX`
suffix inside the plugin root itself. However, we were not ignoring
this folder when enumarating plugins. This would cause some weird
behaviors:
- When a plugin was being installed `pulumi plugin ls` would show a
plugin with a version like `v1.0.0-rc.1.tmp123456`.
- For cases where the version of the plugin had applied
metadata (e.g. our alpha builds where we append the commit hash to the
version via `+gACBDEF123`) the `.tmpXXXXXX` suffix was considered part
of the build metadata. This would mean we could actually end up
selecting these plugins and trying to run them, which was not going to
work correctly (since they are in the process of being
downloaded). Because the way to hit this was using a dev release while
also trying to run a another program that used the same plugin, it was
unlikely that customers would hit this, but we would see this from
time to time in CI, where we run many pulumi programs at the same
time (the `examples` repo is one case where we'd often hit it).
Fixes: #1353
These changes wire up a new script that clones
https://github.com/pulumi/docs, regenerates the appropriate parts of the
docs site, and opens a pull request with the changes. This script
executes on any build in which we publish packages that _also_ has a tag
present.
This was causing an error as follows:
```
error: could not create stack: validating stack properties: invalid stack name: a stack name may only contain alphanumeric, hyphens, underscores, or periods
```
Change is 3.6.2 of typescript have caused their code generation to no
longer emit a call to `this` inside an arrow function, so this test is
no longer causing an error to be thrown.
For now, just accept the baseline, but I'll file an issue so we can
actually get a real failing test here.
Since we don't fully understand what was causing the assert to file,
instead of making changes to return an error when there are equal
plugins, keep the shape of the existing code and just do the work we
need to do to ensure that the assert message has actionable data for
us to look at.
If any templates are marked as `Important: true` then by default show only those templates along with an option to see additional templates.
Fixes#3094.
Present a warm welcome to users when they interactively login.
Also use this as an opportunity to present a "Tip of the Day" - which for now we will use to highlight auto-naming as this has been a common new user question.
We intend to replace PULUMI_TEST_MODE with better testing support
that doesn't suffer from all the pitfalls of our current approach.
Unfortunately, we don't yet have complete guidance or validation
that the new approaches will work for all existing end users. So,
until we do, we'll take a lighter touch approach here, and simply
not encourage new usage of PULUMI_TEST_MODE.
Issue #3045 will remain open to track a mroe permanent fix.
Not all resource providers support Pulumi's Asset and Archive types. In
particular, the Kubernetes provider should reject any resource
definition that contains either of these types.
This commit will introduce two MarshalOptions that will make it easy for
the Kubernetes provider to guarantee that no properties of this type are
in a resource request, as it's deserializing the request from the
engine.
This matches what we tell our customers to do and makes some
downstream testing stuff for beta versions of our python packages
easier (since `pip` has a more straightforward package selection
algorithm than `pipenv`)
