Repository navigation
Worker: a branch that copies another open pull request's commits stacks on it instead of stopping - #453
Merged
Conversation
…ks on it instead of stopping A run stacked on an open pull request stopped at the pull request step when that pull request's branch had been rebased since: the run's branch still held its old commits, which now read as copies under new hashes, and the rebase that should drop them replayed them too, so it conflicted. - The pull request step replays only the branch's own commits onto the other pull request's branch (copies found by patch id are left out). When they don't replay cleanly, that branch is merged in (the model resolves conflicts, the head is never reset) and the merged code becomes one commit on top of it. Either way the pull request is stacked on it. - A branch kept from an earlier attempt is checked right after it is ready, before any implementation, and moved onto the other branch when its own commits replay cleanly. - The run stops only when both fail, saying where the work is kept and what the person can do.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A run stacked on another open pull request stopped at the pull request step ("the branch re-creates N commit(s) of open pull request #N under new hashes ... rebasing onto that branch didn't apply cleanly") after its whole implementation. The other pull request's branch had been rebased after the run started on it, so the run's branch still held that pull request's old commits, which now read as copies under new hashes. The guard then rebased the run's branch onto that branch replaying every commit, copies included, and the old copies conflicted with their rewritten versions. Now the copies are dropped and the pull request is stacked; the run stops only when nothing works, and then says what to do.
Changes
GitHubClient::rebase_onto:git rebase --ontoon GitHub's side. Replays only the branch's own commits (patch-id copies and merge commits left out) onto the other branch, checks the result keeps the branch's code (onto_holds), and moves the branch with a lease.GitHubClient::flatten_onto: once the other branch is merged into the run's branch, moves the branch to one new commit on top of it with exactly the branch's code (same tree), with a lease.stack::before_pr: replays the branch's own commits first. If they don't replay cleanly, it merges the other branch in through the existing conflict resolution (the model resolves conflicts, the head is never reset) and rebuilds the change as one commit on top of it. The pull request is stacked on that branch either way, and its section says which way was used. If both fail, the message says where the work is kept and what the person can do.stack::at_start: a branch kept from an earlier attempt (no open pull request of its own) is checked right after it is ready, before any implementation. It is moved onto the other branch when its own commits replay cleanly.Verification
a_rebase_onto_replays_only_the_branch_s_own_commits), the code check (a_rebase_onto_keeps_the_branch_s_code_or_is_refused), recovery order with replay first and merge only on a conflict (copies_are_dropped_by_replaying_first_and_merging_only_on_a_conflict), own work and the rebuilt commit's message, the stacked section, and the stop message. Existing patch id and dependency pick tests still pass.cargo fmt --all --check,cargo clippy --workspace --all-targets -- -D warnings,cargo test -p worker(1179 passed).