When I run bisect-rustc with a start and end date range, I am seeing two pulls of the start nightly to confirm that the regression is not reproduced at the beginning of the date range when there is no regression at the start date:
checking nightly-2019-07-01 std for x86_64-unknown-linux-gnu: 61.49 MB / 61.49 MB [=========================================] 100.00 % 12.52 MB/s uninstalling nightly-2019-07-01 verifying the start of the range does not reproduce the regression std for x86_64-unknown-linux-gnu: 61.49 MB / 61.49 MB [=========================================] 100.00 % 13.48 MB/s uninstalling nightly-2019-07-01 tested nightly-2019-07-01, got No confirmed the start of the range does not reproduce the regression [ ... ]
I think that this is duplicating the build as well.
The start range check appears to be required in
least_satisfying for calls from
bisect_ci_between. And it appears that the start range check is also required in the
bisect_nightly loop to support the logic there. Thoughts about the addition of a boolean
skip_start_check parameter on
least_satisfying to prevent this block from being executed on the nightly bisect runs only?
Fix for this issue submitted in https://github.com/rust-lang/cargo-bisect-rustc/pull/62
I refactored https://github.com/rust-lang/cargo-bisect-rustc/pull/62 based on Santiago's review. This now addresses duplicated code in the nightly and CI Toolchain testing and addresses the duplicated download/test of the start range check when
--start is specified on the CL. I also cleaned up the std stream reporting during execution so that it is easier to understand what nightly / commit is being tested and the result at that nightly/commit. Let me know what you think.