force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment #131358

onur-ozkan · 2024-10-07T12:49:27Z

When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use git_upstream_merge_base to correctly track modified files as bors commits may be in HEAD but not yet on the upstream remote.

This is also an alternative fix for #129528 since #131331 reverts the previous fix attempts.

rustbot · 2024-10-07T12:49:36Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

onur-ozkan · 2024-10-10T08:01:13Z

thread 'main' panicked at /checkout/src/tools/build_helper/src/git.rs:134:54:
called Result::unwrap() on an Err value: "Cannot find any suitable upstream master branch"

Hmm... More work is needed on this.

@rustbot author

…bzol move dummy commit logic into x86_64-gnu-llvm-18 Doing the dummy commit logic in a runner that uses CI-LLVM breaks in merge CI. This should be properly fixed by rust-lang#131358 (see the [actual problem](rust-lang#131448 (comment))). Since we can also fix it by moving the dummy commit into the runner where we use in-tree LLVM, so why not do that as well?

move dummy commit logic into x86_64-gnu-llvm-18 Doing the dummy commit logic in a runner that uses CI-LLVM breaks in merge CI. This should be properly fixed by rust-lang#131358 (see the [actual problem](rust-lang#131448 (comment))). Since we can also fix it by moving the dummy commit into the runner where we use in-tree LLVM, so why not do that as well?

When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote. Signed-off-by: onur-ozkan <work@onurozkan.dev>

onur-ozkan · 2024-10-12T04:57:09Z

Added new CI step that prepares remote upstream and adjusted the PR description.

@rustbot ready

Signed-off-by: onur-ozkan <work@onurozkan.dev>

rustbot assigned Mark-Simulacrum Oct 7, 2024

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 7, 2024

onur-ozkan force-pushed the 129528 branch from f3dc740 to e936a64 Compare October 10, 2024 06:40

onur-ozkan changed the title ~~exclude upstream check from build_helper::git::get_closest_merge_commit~~ force "HEAD" for non-CI env in in build_helper::git::get_closest_merge_commit Oct 10, 2024

onur-ozkan force-pushed the 129528 branch from e936a64 to 5bc7223 Compare October 10, 2024 06:42