Publish dev versions of the python and node SDKs, so we can consume them
pre-release and make our releases more stable.
Also clean up the publish_npm.sh script a little bit, removing now
unused cruft.
Python 3.12 requires `grpcio` 1.59.0 or higher. Unfortunately, there is
a regression in `grpcio` 1.58.0 through the latest version (currently
1.60.0) which causes any error returned from a Python gRPC server to be
written to stderr, including UNIMPLEMENTED errors. This primarily
affects Python dynamic providers, which don't have implementations for
`CheckConfig` and `DiffConfig`, resulting in a traceback error being
emitted to stderr when the engine calls these, which is visible to
users. This `grpcio` regression has been fixed upstream, but the fix has
not been released yet. We've been waiting for a 1.60.1 patch release.
This has not been great for our Python users who are using Python 3.12.
It's particularly bad for new Pulumi users who are using Python 3.12 and
are trying to get started with Pulumi. For these users, when trying to
install the `pulumi` PyPi package (i.e. via `pulumi new python`) the
installation fails with an error because it is pinned to depending on an
older version of `grpcio` which doesn't work on Python 3.12.
This commit works around the problem by providing default
implementations of `CheckConfig` and `DiffConfig` for python dynamic
providers and the component provider API, so that no error is emitted to
stderr when the engine calls these methods. The default implementations
for these are the same behavior that the engine would use if these
methods had returned UNIMPLEMENTED. I believe these are the only two
methods affected by this. Other methods like `Invoke`, `Call`,
`StreamInvoke`, `Construct`, `Attach`, `GetMapping`, and `GetMappings`,
continue to return UNIMPLEMENTED for dynamic providers, which I think is
OK; I don't believe these will be called by the engine under normal
circumstances.
Out of an abundance of caution, the `pulumi` package continues to depend
on the pinned version of `grpcio` when installing on versions of Python
less than 3.12. On Python 3.12 or greater, we now depend on `grpcio`
`~=1.60.0`. 1.60.0 doesn't have the fix for the regression, but the
workaround should allow things to work on Python 3.12 as before.
Once 1.60.1 is released, we can look into updating the `grpcio`
dependency to `~=1.60.1` for all versions of Python, and possibly revert
the workarounds, if we want.
Note: #14474 added a test for dynamic providers to ensure nothing is
written to stderr. The test would fail if the workaround in this PR did
not work as intended:
https://github.com/pulumi/pulumi/pull/14474/files#diff-d92ccd283e08eadab2597825103e45cdaa96fea93324bc4d4d3b1d2b83c51b76
This PR depends on several other smaller PRs:
- https://github.com/pulumi/pulumi/pull/15220
- https://github.com/pulumi/pulumi/pull/15221
- https://github.com/pulumi/pulumi/pull/15222
- https://github.com/pulumi/pulumi/pull/15223
- https://github.com/pulumi/pulumi/pull/15224
- https://github.com/pulumi/pulumi/pull/15225
- https://github.com/pulumi/pulumi/pull/15226Fixes#14258
When `--rerun-fails` is specified and a test is re-run, the produced
coverage data only contains the coverage from the failed but re-executed
sub-tests. See https://github.com/gotestyourself/gotestsum/issues/274
This change sees how we fare with this disabled as we've recently done
some work to address test flakiness. We'll be relying on the much less
granular `./scripts/retry` for retries, which doesn't have the coverage
problem. The downside is it will re-run all the tests.
The intention if this environment variable is set, is that we want to
run in coverage mode. However in
6af5f0b39d that accidentally got lost. Fix
it.
I noticed this while looking at
https://github.com/pulumi/pulumi/pull/15120 and got confused what the
script is trying to do.
CI added log output to clarify success despite test failure output.
- `run tests` may end with a failing test being the last thing printed,
but it was retried and passed.
Currently we start up and thus compile policy packs one by one. When
multiple policy packs need to be loaded, this increases the start up
time substantially. In previous tests plugins took ~1-3s to start up, so
having multiple of these the time adds up quickly.
Loading them in parallel will help reduce the startup time here.
Fixes#14454
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
Support returning plain values from methods.
Implements Node, Python and Go support.
Remaining:
- [x] test receiving unknowns
- [x] acceptance tests written and passing locally for Node, Python, Go
clients against a Go server
- [x] acceptance tests passing in CI
- [x] tickets filed for remaining languages
- [x] https://github.com/pulumi/pulumi-yaml/issues/499
- [x] https://github.com/pulumi/pulumi-java/issues/1193
- [x] https://github.com/pulumi/pulumi-dotnet/issues/170
Known limitations:
- this is technically a breaking change in case there is code out there
that already uses methods that return Plain: true
- struct-wrapping limitation: the provider for the component resource
needs to still wrap the plain-returning Method response with a 1-arg
struct; by convention the field is named "res", and this is how it
travels through the plumbing
- resources cannot return plain values yet
- the provider for the component resource cannot have unknown
configuration, if it does, the methods will not be called
- Per Luke https://github.com/pulumi/pulumi/issues/11520 this might not
be supported/realizable yet
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
Fixes https://github.com/pulumi/pulumi/issues/12709
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
In general, our test matrix runs on the minimum supported version and
latest version of each language runtime. Python 3.8.x is still a
supported version so try running the tests on 3.8.x.
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
.NET 8 is released, we should ensure tests run against that now.
Fixes https://github.com/pulumi/pulumi/issues/13826.
This brings python inline with node and go as being it's own module and
running codegen via gRPC.
Also includes some improvements to the node and go codegen interfaces
from review.
# Description
Update the following preparing for the CLI release
- pulumi-yaml (v1.2.1 -> v1.2.2)
- pulumi-java (v0.9.0 -> v0.9.6)
- pulumi-dotnet (v3.54.0 -> v3.56.1)
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
We added program generation that assumes availability of generics as
part of https://github.com/pulumi/pulumi/pull/13149, but didn't bump the
version of Go required in the generated go.mod. Currently, Pulumi is
supported on the supported versions of Go, which includes Go 1.20 and
1.21, so here we bump the Go version to the minimum currently supported
version, which also supports all of the code we generate today.
I was curious how this was not already failing tests, and it appears
it's because we delete the `go.mod` file in our tests and recreate it
with `go mod init`. I am unclear why we do that, but it feels like we
should not, exactly to avoid this sort of problem in the future and to
test the actual code we generate.
8696695cdb/pkg/codegen/go/test.go (L25-L28)Fixes#13728.
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
All commits will be squashed by default once we are using merge queues.
This
means there's no need for this linear-history check, since the queue
will
enforce linearity.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
Publishing v3.74.0 to npm failed with `../../scripts/publish_npm.sh: line 13: my_array[2]: unbound variable`.
This commit temporarily changes the `publish_npm.sh` script to not have the unbound variable and comments out jobs in the release workflow that already succeeded, and adds a way to manually dispatch the release workflow to unblock the release. Will use that to re-run the release workflow.
Afterwords, we can revert and address the actual issue.
Previously, it was necessary to enable cgo
and use the system's DNS resolver on macOS.
In Go 1.20, the `net` package was rewritten
to not use cgo at all,
so CGO_ENABLED no longer has any effect there.
In fact, ever since 389860058d,
this setting has been meaningless
because we've been building Darwin binaries
on Ubuntu machines (so cgo can't be enabled anyway).
This commit just deletes this now-unused block.
**Overview**
This re-enables tracking of code coverage.
For Go, there are two kinds of coverage at play:
unit test and integration test coverage.
Unit tests follow the usual pattern of running
`go test -cover -coverprofile=whatever.cov`.
For integration tests, we use the new integration test profiling support
[added in Go 1.20](https://go.dev/testing/coverage/).
In short, the way it works is:
# Build a coverage instrumented binary:
go build -cover
# Set GOCOVERDIR to a directory and run the integration tests
# that will invoke this coverage-instrumented binary.
GOCOVERDIR=$(pwd)/coverage
go test ./tests
# $GOCOVERDIR will now be filled with coverage data
# from every invocation of the coverage-instrumented binary.
# Combine it into a single coverage file:
go tool covdata textfmt -i=$(GOCOVERDIR) -o=out.cov
# The resulting file can be uploaded to codecov as-is.
The above replaces the prior, partially working hacks we had in place
to get coverage-instrumented binaries with `go test -c`
and hijacking the TestMain.
**Notable changes**
- TestMain hijacking is deleted from the Pulumi CLI.
We no longer need this to build coverage-instrumented binaries.
- ProgramTest no longer tracks or passes PULUMI_TEST_COVERAGE_PATH
because the Pulumi binary no longer accepts a test.coverprofile flag.
This information is now in the GOCOVERDIR environment variable.
- We add an `enable-coverage` parameter to the `ci-build-binaries`
workflow to mirror some of the other workflows.
It will produce coverage-instrumented binaries if this is true.
These binaries are then used by `ci-run-test` which will set
`GOCOVERDIR` and merge the coverage results from it.
- Coverage configuration no longer counts tests, testdata,
and Protobuf-generated code against coverage.
- go-wrapper.sh:
Because we're no longer relying on the `go test -c` hack,
this no longer excludes Windows and language providers
from coverage tracking.
- go-test.py and go-wrapper.sh will include pulumi-language-go and
pulumi-language-nodejs in covered packages.
*Other changes*
- go-test.py:
Fixed a bug where `args` parameters added for coverage were ignored.
Note that this change DOES NOT track coverage for calls made to Pulumi
packages by plugins downloaded from external sources,
e.g. provider plugins. Arguably, that's out of scope of coverage
trackcing for the Pulumi repository.
Resolves#8615, #11419
Node 19.8.0 was released ~5 hours ago and we're consistently hitting internal asserts. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0.
We currently run all codegen tests in pkg/codegen/$lang
for every PR.
These tests take quite a while to run and lock up many GitHub workers
for this entire duration.
This change attempts to address this issue
by running codegen tests only for those PRs
that touch the codegen directories.
The machinery to make this work is roughly as follows:
- In the on-pr workflow, when we're figuring out what we're doing,
we check if we've changed codegen files.
We use [paths-filter] to do this.
- We decide whether we want to run codegen tests based on those files,
and pass that onto the test matrix generator.
- The test matrix generator filters out these packages
and their subpackages from the list of tests under consideration.
- Everything else proceeds as normal.
[paths-filter]: https://github.com/dorny/paths-filter
Things to note:
- The test-codegen input defaults to true.
All other invocations will run with codegen tests
so these will continue to run on merge.
Only PRs (from on-pr.yml) set it to false.
- Since the number of tests is remarkably smaller without these tests,
we can significantly reduce the number of partitions we use
for pkg/ unit tests.
This should alleviate pressure on GitHub workers further.
This is a pretty blunt approach to the problem.
If we wanted to be more targeted,
instead of filtering at the get-job-matrix.py level,
we could instead set an environment variable
and add t.Skips in {program,sdk,type}_driver
if that environment variable is set.
And we can still do that in the future
if we decide that maintaining this list is too much.
Resolves#12334
The set-output command has been deprecated by GitHub.
Replace it with the GITHUB_OUTPUT based variant.
This was the only remaining instance of `::set-output`
in the repository after e4e96c96d.
In #11155, we pinned CI to macos-11
because we want to continue to support macOS 11.
This, however hsa created a new issue:
grpcio does not publish wheels for macos-11 anymore
and building it from source takes long enough to kill our CI
(see #12054#12050).
To fix the issue while continuing to support older macOS,
run CI on macos-latest, but leave build jobs and friends on macos-11.
Resolves#12054, #12050
After internal discussion, we determined "smoke" is a misleading
adjective for this category of tests. What we called "smoke tests"
are short integration tests for basic cross-platform functionality.
As a result, these are better named "acceptance" tests, since smoke
tests are intended to be a low water mark at the unit level to sniff
out bigger issues with the build as a whole.