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>

Mark-Simulacrum · 2024-10-12T19:36:05Z

r=me if you think this is ready

onur-ozkan · 2024-10-12T21:29:09Z

@bors r=Mark-Simulacrum

bors · 2024-10-12T21:29:11Z

📌 Commit 4454fa9 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment 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 rust-lang#129528 since rust-lang#131331 reverts the previous fix attempts.

Rollup of 7 pull requests Successful merges: - rust-lang#131120 (Stabilize `const_option`) - rust-lang#131207 (ci: aarch64-gnu-debug job) - rust-lang#131334 (Enable sanitizers for loongarch64-unknown-*) - rust-lang#131358 (force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment) - rust-lang#131418 (Use throw intrinsic from stdarch in wasm libunwind) - rust-lang#131579 (Remap path prefix in the panic message of `tests/ui/meta/revision-bad.rs`) - rust-lang#131591 (add latest crash tests) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 7 pull requests Successful merges: - rust-lang#131120 (Stabilize `const_option`) - rust-lang#131334 (Enable sanitizers for loongarch64-unknown-*) - rust-lang#131358 (force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment) - rust-lang#131418 (Use throw intrinsic from stdarch in wasm libunwind) - rust-lang#131579 (Remap path prefix in the panic message of `tests/ui/meta/revision-bad.rs`) - rust-lang#131591 (add latest crash tests) - rust-lang#131626 (remove a couple of redundant String to String conversion) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#131358 - onur-ozkan:129528, r=Mark-Simulacrum force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment 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 rust-lang#129528 since rust-lang#131331 reverts the previous fix attempts.

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