[DO NOT MERGE] Astro reorg scripts#38325
Conversation
|
| # The PR has conflicts that are NOT from the reorg. We must not | ||
| # touch it — just label it so a human can resolve it manually. | ||
| print(" Non-reorg conflicts present — labeling for manual review.") | ||
| send_to_manual_review(pr_number, dry_run) |
There was a problem hiding this comment.
Note to myself to handle this case slightly differently -- see my comments in the PR description.
| "pr", "list", "--repo", REPO, "--state", "open", | ||
| "--base", BASE_BRANCH, | ||
| "--search", f"-label:{LABEL_NO_CONFLICTS} -label:{LABEL_MANUAL_REVIEW} " | ||
| f"-label:{LABEL_HELP_REQUESTED} -label:{LABEL_SKIP}", |
There was a problem hiding this comment.
Also skip our autofix PRs -- I just noticed that this script tries to process the autofix PRs it made, which doesn't hurt anything (it doesn't find conflicts anyway) but wastes resources.
hestonhoffman
left a comment
hestonhoffman
left a comment
There was a problem hiding this comment.
I left a couple comments and I'll DM you with a test I created for the 3-way merge stuff
There was a problem hiding this comment.
I think this would fail if I ran it cos I have a few more gitignored files/directories that I've assembled over the years that aren't here, but I could add them if I need to run the script.
| "--base", BASE_BRANCH, | ||
| "--search", f"-label:{LABEL_NO_CONFLICTS} -label:{LABEL_MANUAL_REVIEW} " | ||
| f"-label:{LABEL_HELP_REQUESTED} -label:{LABEL_SKIP}", | ||
| "--json", fields, "--limit", str(limit), |
There was a problem hiding this comment.
This limits the PRs fetched by gh, but the doc above calls limit the PRs to take action on, so I think limit is being conflated as both the amount of PRs to fetch and the number of PRs to act on. Perhaps default to ~150 as the gh --limit?
2 participants
What does this PR do? What is the motivation?
We won't actually merge this into master, I'm just setting up a PR for easy code review.
What to review
The config dictating which files will go where:
astro_reorg/config.yamlYou can ignore most of the diff, but a few scripts are worth reviewing:
astro_reorg/execute_reorg.py, which reorgs any regular branchastro_reorg/resolve_pr_conflicts.py, which processes all of the PRs in the docs repo to auto-fix any conflicts that arose from the reorg being merged into masterResources
You may find
astro_reorg/docs/pr_handling_details.mduseful, since it describes the resolving script's flow in English.How this was tested
I set up a test run as described in
astro_reorg/docs/test_setup.md, then ran the resolver script against it. The results are linked below.For example, you can see that the changes in this autofix PR correctly replay the changes seen in this closed conflicting PR, except the changes are applied to the new
hugofolder.You can view all test PRs (including past test PRs) here. The 4 open PRs and 2 recently closed PRs are the same ones listed below.
Test PRs, and their expected result (this list was generated by
create_test_prs.py)[TEST] Minor wording tweak in getting started intro (auto-fixable)
Auto-fixed. The conflict is purely reorg-caused (file moved from
content/tohugo/content/). The resolver opens a new PR with the commit replayed at the post-reorg path, closes this PR, and labels itastro-reorg-autofixed.[TEST] WIP PR with reorg conflict (should be skipped by resolver)
Skipped (WIP). The conflict is reorg-caused and would otherwise be auto-fixable, but the PR carries the
WORK IN PROGRESSlabel. The resolver posts a comment explaining the situation, appliesastro-reorg-skip, and leaves the PR open for the author to act on.[TEST] Unresolvable reorg conflict (base edited the same line) (not auto-fixable)
Manual review (unresolvable reorg conflict). The conflict is classified as reorg-caused, but the base branch also edited the same line at the post-reorg path (
hugo/content/en/getting_started/_index.md), sogit am --3waycannot replay the patch. The resolver labels this PRastro-reorg-manual-reviewand posts a comment.[TEST] Non-reorg conflict on a top-level file (not auto-fixable)
Manual review (non-reorg conflict). The conflict is in
CONTRIBUTING.md, a top-level file the reorg never moves. The resolver classifies it as an unrelated conflict and immediately labels this PRastro-reorg-manual-reviewwithout attempting an auto-fix.NOTE: I don't like how this is handled, since the comment is confusing here (it acts as though the conflicts are from the reorg, but they aren't). I think this case should be labeled with
astro-reorg-no-conflictsand skipped. I've added a comment in the code of this PR so I don't forget to adjust it.[TEST] New page with nav link, no base conflict (auto-fixable)
Auto-fixed. The PR adds a new page at a pre-reorg path (a "wrong-path addition") and links it in the nav menu. Both changes are reorg-caused and the base branch did not touch that menu line, so the resolver replays both commits cleanly at the post-reorg paths, opens a new PR, closes this one, and labels it
astro-reorg-autofixed.[TEST] New page with nav link (base edited the same menu line) (not auto-fixable)
Manual review (unresolvable reorg conflict). The PR adds a new page at a pre-reorg path and inserts a nav menu entry. The conflict is classified as reorg-caused, but the base branch also renamed the same menu heading, so
git am --3waycannot replay the nav edit. The resolver labels this PRastro-reorg-manual-reviewand posts a comment.Logs that you might find useful
Output from
create_test_prs.pyOutput from
resolve_pr_conflicts.py