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
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. -->
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. -->
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].
<!---
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 # (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. -->
# Description
This PR removes Bors in favor of native GitHub merge queues. A very
similar
cutover was tested and verified in
https://github.com/pulumi/watchutil-rs/pull/39.
# Deployment plan
* [x] Find some time where PRs aren't being merged. This is mostly to
minimize confusion
while we're futzing with branch protections.
* [x] Update the repo's branch protection rules to match
https://github.com/pulumi/watchutil-rs/pull/38:
* "Allow specified actors to bypass required pull requests": "bors" →
Unchecked
* "Status checks that are required": "bors" → "ci-ok"
* "Require merge queue": Unchecked → Checked
* "Only merge non-failing pull requests" → Unchecked
* "Merge method" → Squash and merge
* [ ] Merge this PR using the "Merge when ready" button.
* [ ] If it merges successfully: confirm the prepare-release step ran
and published
pre-release artifacts.
* [ ] If the merge fails: it's possible we'll need to tweak steps
slightly
(e.g. if the step's name doesn't match the branch protection rule). The
end goal is a "ci-ok" step in both the PR and merge workflows that
captures whether everything is green.
* [ ] If the issues aren't immediately resolvable, revert the changes
made
to branch protection settings. Folks will continue to merge with
Bors.
If all goes well, we should be able to continue merging with MQ for a
while --
at least long enough to cut a new CLI release. Once we're confident we
won't
need to roll back:
* [ ] Delete branch protection rules for:
* staging
* testing
* [ ] Remove pu/pu from https://app.bors.tech/repositories
Fixes https://github.com/pulumi/pulumi/issues/13501
## 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. -->