Merge branch 'release/0.13.4'

[jpnurmi]

The release bot failed to merge release/0.13.4 into master.

Not 100% sure what went wrong. There are no conflicts in CHANGELOG.md. Only #1604 and #1605 were merged while the release was running. Possibly related to:

Error: fatal: could not read Username for 'https://github.com/': No such device or address

Anyway, the output contains instructions to manually merge release/0.13.4 into master.

Originally posted by @github-actions in getsentry/publish#7613

Published successfully: run#23662543196

In the Publish using Craft step:

[info] [warn] Failed to merge release branch "release/0.13.4" into the target branch.
This is likely due to a merge conflict (e.g., in CHANGELOG.md).
All publish targets completed successfully — only the post-publish merge failed.
To resolve manually:
1. Merge the release branch into the target branch, resolving conflicts
2. Delete the release branch: git push origin --delete release/0.13.4
Error: fatal: could not read Username for 'https://github.com/': No such device or address
[success] Version 0.13.4 has been published!

#skip-changelog

[supervacuus]

Yeah, I see... There have been no changes in the change log since the release was triggered. So changes on master that would prevent auto-merges were not the cause here.

@BYK, do you have an explanation for why this failed?

This should definitely be merged, but I see that the new Validate PR workflow also failed. Maybe there is a connection between these new workflows and a central auth-related capability they depend on that still does not work (or just a missing new env or secret). Could imagine the same thing affected the publish run.

[BYK]

Looks like the build/deploy took too long and the temporary GITHUB_TOKEN expired in the meantime. I'm exploring a bit more to make sure

[BYK]

Yeah the token lives for an hour and this took 1h 23m. We should probably avoid triggering deploys before we get a successful build on release branches to avoid this (and also wasting CI resources as publish will just wait till the CI passes). I'll try to see if we can find a better way rather than simply blocking

[supervacuus]

Yeah the token lives for an hour and this took 1h 23m. We should probably avoid triggering deploys before we get a successful build on release branches to avoid this (and also wasting CI resources as publish will just wait till the CI passes). I'll try to see if we can find a better way rather than simply blocking

Oh, okay, that makes sense. Thanks for taking a look. That is already useful feedback. I primarily looped you in in case this was a more systemic issue.

[BYK]

@supervacuusgetsentry/publish#7664

Once this (and related Craft patches land and get released) you'll need to update your version in the release.yml workflow and should pick this up.

[supervacuus]

Hi @BYK, followed your recent changes and, if I understood correctly, nothing in release.yml needs to change.

We also released 0.13.5 two days ago; it looked like your changes were already in effect, but I see no pending/ready labels being applied. I just want to check whether what I am seeing is what you expect, or if I still need to update anything in our release.yml.

Here is the publish run for that release: https://github.com/getsentry/publish/actions/runs/24087528569

• the CI run in the publish issue started at the time the issue was created at 4:17PM (GMT+2) and lasted for almost 40 minutes (i.e. stopping at 4:57PM-ish).
• the accepted label was manually added 4:43PM (GMT+2) (so there is 14 minute offset)
• There is a skipped "Waiting for CI" Job that is never executed. I would expect this to be waiting, right? But there is no ci-pending or at least I can't see it.
• We still "actively" wait in the Publish using craft step of the Release a new version job (last log line at 14:56:51 (UTC), meaning exactly the CI stopping time).

So, I guess we either have to add a parameter to the prepare-release action, change our craft config, or have to otherwise initiate ci-pending from somewhere. Or am I completely off?

[supervacuus]

Or can this not work before getsentry/publish#7674 is merged?

[BYK]

@supervacuus the system was not deployed fully at the time you tried. Now it is. You should immediately get a ci-pending label which should then be updated later (in 5 minute intervals) when CI passes. If you add accepted label before ci-ready label is added, the bot will tell you that it's waiting for CI but won't really run Craft in the background (will just monitor).

I'm working with SECOPS to make this even more efficient but should be fine for now.

[BYK]

Example: getsentry/publish#7770

[supervacuus]

Awesome, thx @BYK !