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)
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
<!---
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`
<!---
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
We're investigating odd behavior with the queue. I've disabled the
"Require linear history" check and I want to test whether that affects
the merge behavior.
Refs https://github.com/pulumi/pulumi/issues/13741.
## 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. -->
We currently upload coverage artifacts to codecov every 12 hours via the periodic-coverage cron workflow, which runs the full suite of tests against master, as well as during PRs, which runs a subset of tests for the PR.
We currently see some discrepancies in the data in codecov. One theory is the difference in tests between PRs and master.
This change makes it so we no longer upload coverage artifacts during PRs, to helpfully keep the data in codecov clean for trends over time.
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
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.
11118: ci: Update post-release PR to align with release process r=AaronFriel a=AaronFriel
As the release process now includes a "freeze PR" which updates `.version` _prior_ to release, the post-release PR shouldn't attempt to make the same change, as it causes a merge conflict.
This removes the notion of "next-version" from the CI scripts, as that post-release PR was the only place it was used.
The post-release PR can also be auto-merged, so `queue-merge` is set to true.
11249: ci: Reduce Windows test parallelism r=AaronFriel a=AaronFriel
Increases likelihood of CI passing on Windows due to longstanding CPU exhaustion bug on runners. (GitHub support ticket 1791026 on my account.)
11284: Make convert's pcl output yaml agnostic r=Frassle a=Frassle
<!---
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. -->
We're going to use convert for more data sources than just YAML (e.g. hcl, arm, etc). So we don't want the PCL output option to be YAML specific given it should be usable for any input source.
11288: [cli] Update the survey module r=pgavlin a=pgavlin
Pick up the bugfix to https://github.com/AlecAivazis/survey/issues/228.
This also provides a cleaner API for setting survey icons.
11289: [cli] Add a newline in the refresh confirmation prompt r=pgavlin a=pgavlin
The lack of a newline causes the prompt to wrap in terminals that are fewer than 120 or so columns wide. The wrapping confuses the survey package's redraw, which causes the repeated prompts each time the survey is redrawn (i.e. on every keypress). Removing the wrapping by adding a newline avoids this issue.
Co-authored-by: Aaron Friel <mayreply@aaronfriel.com>
Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Pat Gavlin <pat@pulumi.com>