Before every CI job we currently check whether the Go cache is primed,
and if not compile all the tests to prime it. However that check is
currently wrong. `steps.setup-go.outputs.cache-hit` is a boolean
variable, however we compare it against a string 'true'. Since we are
comparing for inequality, this check is always true, so we are always
priming the cache, even if it is already primed.
Fix this check, so we can only prime the cache when it needs to be and
don't waste extra CI time to prime the cache when it already might be.
h/t again to @iamricard for noticing that we are taking a long time to
prime the cache in some cases.
Currently we do our dev releases while running CI for the merge queue,
which adds to the time it takes for things to get through the merge
queue, slowing our development process down.
However there's no really good reason to do dev releases pre-merge. The
pre-merge checks are there to make sure the main branch is always green.
We already know the binaries will be able to be built successfully since
we do that for integration tests. And if the network fails for uploading
the binaries we can always just retry the CI job, which we can do for a
on-push CI job, but isn't useful for the merge CI job since the PR will
already have been taken out of the queue.
h/t to @iamricard who suggested this during a conversation this weekend.
I really don't see a reason not to do this. We should probably do the
same for the release builds, but it's probably best to start with dev
releases since those are less important, and this should be hopefully
not very controversial.
/xref https://github.com/pulumi/pulumi/issues/15416
We disabled this because the way we were tagging the version was
incorrect as we were tagging a version outside of the main branch, but
the way we fixed it the first time around (trying to push the commits
directly to master) didn't work because of branch protections.
Fix this now by tagging pkg during merge, using the version we get from
the commit message.
I think we can actually test this one by creating a fake "Changelog and
go.mod updates for v0.0.9999" PR, merging that, and deleting that tag
again afterwards. It's going to be after the fact testing, but at least
we should be able to do it before the release.
---------
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
<!---
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
This PR adds a prefix to the titles of PRs created in provider repos for
downstream tests. It'd make it easier for provider maintainers to
recognise test PRs from real upgrades and help with not automatically
raising P1 issues on the PR CI failing.
We added a similar change to the bridge:
https://github.com/pulumi/pulumi-terraform-bridge/pull/1726
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
Fixes # (issue)
## 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. -->
This commit contains two changes:
1. Temporarily comment out jobs that have already successfully run in
the `release.yml` workflow. See
https://github.com/pulumi/pulumi/actions/runs/8117091017/job/22188577398
2. Add a way to manually dispatch a release via
`on-release-manual-dispatch.yml` workflow. The new file is a copy of
`on-release.yml`, but setup to allow manual trigger with input
variables, rather than being triggered by a release.
This change will be reverted after v3.108.1 is fully released.
This PR reverts the change from
https://github.com/pulumi/pulumi/pull/15515 because it's currently
broken, and even if we fix the problem where it is broken, I'm not sure
we can make it work without unchecking the "Do not allow bypassing the
above settings" in `master`'s branch protection rules, which I think we
do want to keep checked (some more details in #15554).
An additional commit also temporarily disables tagging `pkg/<version>`
in the workflow. Instead, that will have to be done manually as part of
the release process when the change lands in `master`. As a fast follow,
I'd like to see if there's a way we can automate adding the tag after
the change lands in master, perhaps if the PR has a certain label or is
named a certain way?
I mainly want to do this because it looks like we may have a Node.js SDK
regression and will need to do a quick v3.108.1 release, and I want to
make sure we can get that out without a broken workflow and needing to
go through a bunch of manual temporary workarounds to unblock that
release.
@tgummerer, what do you think?
Fixes#15554
(If we merge this, we should re-open
https://github.com/pulumi/pulumi/issues/15458 to track fixing this)
This commit contains two changes:
1. Temporarily comment out jobs that have already successfully run in
the `release.yml` workflow. See
https://github.com/pulumi/pulumi/actions/runs/8106099187
2. Add a way to manually dispatch a release via
`on-release-manual-dispatch.yml` workflow. The new file is a copy of
`on-release.yml`, but setup to allow manual trigger with input
variables, rather than being triggered by a release.
This change will be reverted after v3.108.0 is fully released.
Post release, we need to update the changelog (clear out all the pending
entries), and update the go.mod in pkg, and also tag the latest version
of that. Currently we create a new PR for that. However since we are
using squash merges, and need to do the tagging while creating the PR,
we're tagging a commit that doesn't end up on the main branch. This
means the Go tooling doesn't work properly with pkg. See also
https://github.com/pulumi/pulumi/issues/15458.
There is nothing really we are doing with that PR other than merging it
(in fact queue-merge is set to true, so it should be queued and merged
automatically, but that doesn't seem to work).
Because of that, we can just tag the release, and push it straight to
the main branch instead. This removes one human step from the release
process and makes the Go tooling work correctly.
The only potential downsides of this change are:
- a small race condition, if a commit gets merged just before we do the
rebase we might end up failing that and the release workflow fails. This
is very unlikely, since the release process should be relatively quick.
- we need to adjust the branch protection rules for pulumi-bot so it's
able to push to the main branch directly. This should not be a problem,
since it's an automated tool, so all of its potential activity has been
reviewed by humans beforehand.
Curious especially if @justinvp has any thoughts on this, since he's
mostly taking care of the release process.
Fixes https://github.com/pulumi/pulumi/issues/15458
Currently we release a new dev SDK when nothing changed because the
condition here is set incorrectly. We want to create a new release when
the exit code is non-zero, so we need to check for `if ! git diff`.
<!---
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
Initial support pnpm. Note that this does not support pnpm workspaces
yet.
This also does not handle passing the package manager through from
`pulumi new`. Once a user manually runs pnpm, creating a pnpm-lock.yaml,
we'll detect that and pnpm.
Fixes https://github.com/pulumi/pulumi/issues/15455
## 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. -->
For testing purposes we released a new dev SDK on every merge. However
this is unnecessary once dev releases are working, and just clogs up the
release page/uses extra storage space for the package hosts.
Only publish new dev releases when something actually changed in the
SDK, otherwise we can skip publishing.
In https://github.com/pulumi/pulumi/pull/15299 we changed the versioning
scheme of dev releases slightly, as npm and python have slightly
different requirements. However this also means that names of CLI dev
releases changed, and thus downloads failed.
Fix that by updating the latest-dev-version file to the new versioning
scheme.
Fixes https://github.com/pulumi/pulumi/issues/15443
## 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. -->
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.
resourcedocsgen has been remved from the pulumi/docs repo in
https://github.com/pulumi/docs/pull/10009, so now the related CI build
fails. Get it from the pulumi/registry repository instead, where it
lives now.
Note that this requires https://github.com/pulumi/docs/pull/10053 to be
merged first to update the script to no longer try to build the tool.
I'm not sure why the CI job didn't break earlier, the first time I
noticed it being broken was in
https://github.com/pulumi/pulumi/pull/14156.
## 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. -->
This TODO has been there since this
6ef7ef64d6 was merged to the main branch,
but the flag was always true, and the comment also tells us to set it to
true. Setting it to true is still the right thing, so let's just get rid
of the confusing comment.
Just a minor cleanup I noticed while working on some CI stuff.
I was watching the merge queue quite closely today, and it's continually
stuck waiting to run jobs on MacOS runners. However when the jobs are
running on them they tend to be faster than e.g. Windows runners, often
running the tests assigned to them in 2 min, vs. 8 min on windows.
In addition we're spending quite a bit of time to setup the actual
running of tests, and by spreading the tests out over multiple runners
that time multiplies. Given the macos runners are the most expensive
ones that probably also adds up.
Given all that, we can reduce the number of MacOS runners we're using,
while not trading that off against longer overall CI times, as those are
limited by slower jobs.
Unfortunately this results in some duplication in the ci job, but I
think the tradeoff here might be worth it.
(Also happy to hear if we think this isn't worth the extra messiness in
the GitHub actions files, as usually the merge queue isn't as bad as it
is today, so this isn't that much of an issue)
---------
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
In preparation for supporting Python 3.12...
As of Python 3.12, `setuptools` is no longer installed by default into a
virtual environment created with `python -m venv`
(https://github.com/python/cpython/issues/95299). It must be explicitly
installed via `python -m pip install setuptools`.
# Description
This is quite an awkward test because it depends on a secret from the
environment. However I don't really know how to do this otherwise since
we do need this SAS token, and that's a secret we need, so we have to
inject it through the environment.
/xref #15138
## 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.
-->
- [ ] 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. -->
<!---
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
go:embed can not traverse paths upwards, move .version so we can embed
it. This enables us to have the version available outside of binary
builds (where we use linker flags to embed the version in
sdk/go/common/version/version.go).
This is useful for automation API, where we want to have the current
version available to us, but don't want to force consumers of the API to
build and test with linker flags.
Blocking for https://github.com/pulumi/pulumi/pull/15049
## 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`
These secrets are required for the acceptance tests to run correctly, as
we're getting false failures otherwise. This is safe, since we're also
using these secrets in other CI jobs, and always review code before
running the acceptance tests.
I noticed in https://github.com/pulumi/pulumi/pull/15173 that the tests
introduced in https://github.com/pulumi/pulumi/pull/14649 are failing.
Turns out, we can't easily change the credentials of the Python publish
step because it will run the publish command as defined in `v3.100.0`
which is using the old username/password, rather than from `master`
which has been updated to use the API token.
Instead, the wheel artifact from
https://github.com/pulumi/pulumi/releases/tag/v3.100.0 has been manually
published.
This change temporarily updates the release workflow to no longer do any
SDK publishing steps, as these are now all complete. Once this has
merged, I'll dispatch the release, which will run all subsequent release
steps.
Then we can revert the temporary workflow changes.
Part of #15043
The windows tests keep failing, without a good indication of what is
actually failing, and no logs in the "run tests". Maybe adding the test
command we're actually running will give us some additional information
to help track the issue down.
Not sure if this will actually help with anything, but I also don't
think it can hurt.
/xref https://github.com/pulumi/pulumi/issues/14992
This commit contains two changes:
1. Temporarily comment out jobs that have already successfully run in
the `release.yml` workflow. See
https://github.com/pulumi/pulumi/actions/runs/7404894608
2. Add a way to manually dispatch a release via
`on-release-manual-dispatch.yml` workflow. The new file is a copy of
`on-release.yml`, but setup to allow manual trigger with input
variables, rather than being triggered by a release.
This change will be reverted after v3.100.0 is fully released.
Part of #15043
Add a test showing the problems we ran into when upgrading from
gocloud.dev 0.27.0 to 0.28.0 and 0.29.0. It's a little bit awkward,
since the issue only happens when upgrading form an encrypted key
generated with the old version of gocloud.dev to a newer version of
gocloud.dev.
Fixes https://github.com/pulumi/pulumi/issues/11986
---------
Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
For windows we generate zip files, not tar.gz, so make sure to also
upload those.
Also upload the signature files a bit more explicitly. Because we have
two sign processes running (first for building the release artifacts and
then the dev artifacts), we get .sig.sig files otherwise, but we don't
need these, so be more selective here.
## 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 https://github.com/pulumi/pulumi/pull/14966 we tried to correct the
quoting of the dev-version. However the name written to the
$GITHUB_OUTPUT file was wrong there. Fix that.
## 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. -->
Unfortunately https://github.com/pulumi/pulumi/pull/14964 didn't quite
do what we wanted it to, and the version number still contained the
extra quotes. Investigating a bit more, I now believe the "set-output"
script is the culprit because it does some extra quoting. Since we don't
need any extra escaping here, we can just write to the file containing
the outputs directly instead, which will hopefully fix the issue.
## 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. -->
GitHub actions interprets these quotes literally, so the version we end
up with includes the quotes, and will therefore end up in the form of
`v"1.0.0-11-gdeadbeef" in the output. Remove the extra quotes as they
are not needed.
It's a bit awkward to test this, but I *think* this should do the trick.
The latest-dev-version file is not supposed to include a 'v' prefix.
However the `git describe` output includes it. Strip that from the
string before dispatching the CI job that updates the latest-dev-version
file.
## 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. -->
https://github.com/pulumi/pulumi/pull/14640/files#diff-42e26dc67aed8aa3edb2472b4403288c1699fb6dc47419b9a475f0f224fe4689
inadvertently got rid of the v prefix in the version in pulumi about.
Add it back. Also make sure we don't get a duplicate `v` prefix in the
dev releases.
Fixes#14800
## 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. -->
The reason for this is twofold:
- Once ci-ok is run, GitHub deletes the merge queue branch, and thus the
checkout in the update-dev-version step fails.
- If we do the update-dev-version after ci-ok, we might still merge the
changes even though we haven't updated the dev version properly. This
isn't a big deal, but can be confusing nonetheless.
## 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. -->
If CI succeeds for the merge, we'll want to update the latest dev
version, as we know this is going to be merged, and we published the
binaries to AWS. Dispatch the correct event to update that file in
the pulumi/docs repository.
/xref https://github.com/pulumi/pulumi/issues/14623
## 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. -->
Create a CI job that uploads artifacts to S3 after every build. These
artifacts will have a version number derived from `git describe` so they
can be uniquely identified. After this PR is merged, these artifacts
will be able to be downloaded through `get.pulumi.com` by specifying the
exact version number, and in the future through a dev channel.
Fixes#14622
## 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. -->
Fixes#14817
As a follow-up to #14804, we need to re-enable code coverage without
releases being built with coverage. #14804 includes a test in the
release job to catch `pulumi` being released with coverage data.
Also fixes the test to check that the pulumi binary is not built with
coverage.
Background:
Coverage was disabled on merge jobs in order to fix
[pulumi/pulumi#14799].
[pulumi/pulumi#14716] removed nightly coverage workflows in favor of
collecting coverage on merges [pulumi/pulumi#14727].
The binaries built with coverage were used in the downstream
prepare-release job causing a noticable bug [pulumi/pulumi#14799].
See https://goreleaser.com/deprecations/#-rm-dist
Just a very minor thing I noticed while working on
https://github.com/pulumi/pulumi/issues/14622, probably best to switch
to non-deprecated options eventually.
## 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. -->
Bumps @actions/setup-go to v5.
.github/workflows/ci-run-test.yml uses @actions/setup-go@v3 which uses
@actions/cache@v3.
This version suffers from a bug where it will hang forever when
downloading a segment and will timeout the job.
According to
https://github.com/actions/cache/blob/6a1a45d/tips-and-workarounds.md#cache-segment-restore-timeout
v3.0.8 adds SEGMENT_DOWNLOAD_TIMEOUT_MINS with a default of 10 minutes
which should alleviate our CI hangs.
Only applying this to `ci-run-test.yml` to limit the scope of the
change.