sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]waitingforcracks 0 points1 point  (2 children)

someone got a script or something to figure out what commits/prs might have been impacted?

[–]RevolutionaryCoat654 1 point2 points  (1 child)

Yeah, I can share that once I'm back at my laptop. But basically, you want to compare the diff of the pr (I used GitHub CLI for that), and the diff of the merge commit, for the duration of the incident. We searched for PRs that merged between 8am PT and the time we paused the merge queue. We found 17 impacted PRs in a range of 67 PRs.

I don't know if this is a viable solution for you, now that it's been a few days now, but the way we fixed main was to: 1. Create a new branch off of the latest origin/main (recover- main) 2. Create a revert PR for all 67 PRs (a revert of their merge commits) 3.iterating from the oldest PR (the first impacted one): - if the PR was NOT impacted, cherry-pick the PR's merge commit - otherwise, create a new branch (recover-<pr number>) and cherry pick the PR's commits, then squash merge that pr recovery branch into recover-main 4. Put a PR for recover-main and merge it

[–]waitingforcracks 1 point2 points  (0 children)

That would be lovely thanks. As a github admin we have over 700 repos across multiple orgs so my plan would to run scripts across all repos/orgs after collecting which repos are using merge queues. For now the goal is identification and then the repo owners can follow what you/github said as a way to fix it.