Commit Graph

12 Commits

Author SHA1 Message Date
Justin Van Patten 348a976084
ci: Use latest version of actions/checkout ()
Upgrade all workflows to the latest version of actions/checkout (which
uses node 20 runtime).
2024-03-30 15:53:47 +00:00
Justin Van Patten a415f4c6b3
ci: Use the latest version of actions/setup-go ()
Upgrade all workflows to the latest version of actions/setup-go (which
uses node 20 runtime).
2024-03-29 16:00:53 +00:00
Thomas Gummerer 4873a32480
tag pkg automatically again ()
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>
2024-03-11 08:45:15 +00:00
Justin Van Patten ec409d975c ci: Fix post-release PR workflow to push the branch
I'd commented this out as part of commenting out the tagging of `pkg/<version>`, but we do need to push the branch before creating the PR.
2024-03-01 13:26:07 -08:00
Justin Van Patten add56786a3
Revert "push post-release changelog and go.mod updates straight to master" ()
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 ).

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 

(If we merge this, we should re-open
https://github.com/pulumi/pulumi/issues/15458 to track fixing this)
2024-03-01 13:31:16 +00:00
Thomas Gummerer 3b4715ae1b
push post-release changelog and go.mod updates straight to master ()
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
2024-02-27 15:41:35 +00:00
Justin Van Patten 103cbb12a7
ci: Add required `--squash` flag to `gh pr merge` ()
As part of the release workflow, we use the GitHub CLI to open a PR to
update the changelog and go.mod files. This has been failing when
running `gh pr merge` with:

```
--merge, --rebase, or --squash required when not running interactively
```

This adds the `--squash` flag to make it happy, which is the same
setting for the merge queue.

The need to specify this seems like a bug in the GH CLI. When trying
this out locally with `--squash` it works, but says "The merge strategy
for master is set by the merge queue". Anyway, we'll specify it for now
so it works.

Fixes 
2023-09-09 17:52:12 +00:00
Abhinav Gupta d2ccfb8865
ci(release-pr): gh pr create needs a body ()
The release PR job currently fails with the error:

must provide `--title` and `--body` (or `--fill` or `fill-first`) when
not running interactively

Previously, body used to be `""` or `"bors merge"`.
Now that we no longer use bors, the body needs something in it.
2023-08-26 00:19:40 +00:00
Bryce Lampe f3d0feb8b2
ci: Remove Bors ()
# 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. -->
2023-08-12 01:36:48 +00:00
Aaron Friel 8b1b37d82f ci: Update post-release PR to align with release process 2022-10-18 22:45:59 -07:00
Aaron Friel 6ef7ef64d6 ci: Enable testing of language version sets 2022-09-21 09:48:38 -07:00
Aaron Friel 272b987791 ci: ensure trunk is always green 2022-09-13 13:38:14 -07:00