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