-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move dummy commit logic into x86_64-gnu-llvm-18 #131531
Conversation
rustbot has assigned @Mark-Simulacrum. Use |
e4ffcf0
to
9c8d9df
Compare
There are too many PRs assigned to Mark. r? Kobzol (feel free to "r" it again) |
This comment has been minimized.
This comment has been minimized.
9c8d9df
to
c25d732
Compare
This whole test setup (including creating the commit) should ideally be done within bootstrap :( But I realize that it would be quite hard to do with our basic testing setup. I don't understand why the specific runner is important for the test though. Shouldn't we write the test in a way that the tested |
It’s not related to how we write tests. When test is run the external config is already ignored. But when we invoke |
I think this shouldn't be done in bootstrap, otherwise the test will always think "there is a change on the compiler". |
I see. So the real issue is that we run tests through
Well ideally, the test should literally clone/copy rustc into a separate folder, setup config, do a test commit and assert that it works :) But our testing infrastructure (and bootstrap itself) is of course currently far away from something like this. You can r=me once PR CI is green. |
I meant the test will always consider that there are changes on the compiler and it will not cover the other way, but yeah that can be handled in the test logic too. |
I just tried creating two tests (one with commit logic and one without), but then I realized that the commit logic won't work in runners where
@bors r=Kobzol |
…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?
…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?
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#131464 (Update wasm-component-ld to 0.5.10) - rust-lang#131498 (Consider outermost const-anon in `non_local_def` lint) - rust-lang#131512 (Fixing rustDoc for LayoutError.) - rust-lang#131529 (rustdoc-json-types: fix typo in comment) - rust-lang#131531 (move dummy commit logic into x86_64-gnu-llvm-18) Failed merges: - rust-lang#131476 (coverage: Include the highest counter ID seen in `.cov-map` dumps) r? `@ghost` `@rustbot` modify labels: rollup
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?
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
Signed-off-by: onur-ozkan <work@onurozkan.dev>
c25d732
to
b72dbd5
Compare
Just realized @bors r=Kobzol |
From #131448 (comment):
So let's prioritize this a bit. @bors p=1 |
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?
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
I have no idea what happened, but it doesn't seem related to what this PR does. |
@bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1bc403d): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (secondary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -2.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 780.968s -> 782.608s (0.21%) |
Doing the dummy commit logic in a runner that uses CI-LLVM breaks in merge CI. This should be properly fixed by #131358 (see the actual problem). 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?