You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: Make sure that we can bootstrap with cfg(parallel_queries). #48607
changed the title [-]CI: Make sure the we can bootstrap with cfg(parallel_queries).[/-][+]CI: Make sure that we can bootstrap with cfg(parallel_queries).[/+]on Mar 9, 2018
We unfortunately don't have a lot of spare cycles on CI right now, both in terms of overall capacity and extra time to run more tests on builders (we're already timing out all over the place). If this is "things are on fire we really need this" then this can be prioritized, but otherwise this probably won't happen for awhile.
I think it would be great if we could at least make sure that stage 0 builds with cfg(parallel_queries). Down the line we'll have to run test too but that's not so urgent.
That may be easier to do so, yeah. We could probably do something like RUSTFLAGS_STAGE0=... on whatever builder executes the fastest today, such as x86_64-gnu-debug
Running x.py check first would also serve to quickly reject PRs with compile errors. I'm not sure that matters for the bors queue, but it might help with PR builds.
Oh yeah that could for sure work! The check build finishes so quickly we could just add a slew of extra builders on Travis. They can get scheduled in the cracks between other builds
Closing as per the above. @aturon is taking over some of the parallel compiler review work though so I think as we move closer to making that stable we'll probably want to enable more builders and such but keeping this open doesn't seem too useful.
Activity
Zoxc commentedon Mar 9, 2018
I would also like Travis PRs builds to run
x.py checkwithcfg(parallel_queries)before doing the normal build withoutcfg(parallel_queries).Zoxc commentedon Mar 9, 2018
cc @rust-lang/infra
[-]CI: Make sure the we can bootstrap with cfg(parallel_queries).[/-][+]CI: Make sure that we can bootstrap with cfg(parallel_queries).[/+]alexcrichton commentedon Mar 9, 2018
We unfortunately don't have a lot of spare cycles on CI right now, both in terms of overall capacity and extra time to run more tests on builders (we're already timing out all over the place). If this is "things are on fire we really need this" then this can be prioritized, but otherwise this probably won't happen for awhile.
alexcrichton commentedon Mar 9, 2018
er, didn't mean to close
michaelwoerister commentedon Mar 12, 2018
I think it would be great if we could at least make sure that stage 0 builds with
cfg(parallel_queries). Down the line we'll have to run test too but that's not so urgent.alexcrichton commentedon Mar 12, 2018
That may be easier to do so, yeah. We could probably do something like
RUSTFLAGS_STAGE0=...on whatever builder executes the fastest today, such as x86_64-gnu-debugZoxc commentedon Mar 12, 2018
I'd be satisfied with running
x.py checkon some configuration which should take like 6 minutes (assuming it skips LLVM).Zoxc commentedon Mar 16, 2018
Running
x.py checkfirst would also serve to quickly reject PRs with compile errors. I'm not sure that matters for the bors queue, but it might help with PR builds.alexcrichton commentedon Mar 16, 2018
Oh yeah that could for sure work! The
checkbuild finishes so quickly we could just add a slew of extra builders on Travis. They can get scheduled in the cracks between other buildsmichaelwoerister commentedon Mar 16, 2018
That seems like a good first step.
michaelwoerister commentedon May 4, 2018
The
./x.py checkapproach was added in #49120 and #50444 extends it a little.Rollup merge of rust-lang#50444 - michaelwoerister:check-parallel-que…
Auto merge of #50444 - michaelwoerister:check-parallel-queries-in-ci,…
Mark-Simulacrum commentedon Aug 19, 2019
Closing as per the above. @aturon is taking over some of the parallel compiler review work though so I think as we move closer to making that stable we'll probably want to enable more builders and such but keeping this open doesn't seem too useful.