feat(cli): add cratesfyi command to queue rebuilds for specific broken nightly dates #2996
Conversation
github-actions
bot
added
the
S-waiting-on-review
syphar
left a comment
syphar
left a comment
There was a problem hiding this comment.
Thank you for working on this! Looks already pretty good, only small things IMO.
I'm not 100% sure whether this is correct: I'm assuming that the nightly version of rustc always matches the version of rustdoc used, as they're shipped together as part of the nightly toolchain. This allows me to use the already existing rustc_nightly_date field on the builds table to filter by date.
Yep, this is absolutely the correct field. Nightly version = rustdoc version for us.
Also this is exactly why I added the field.
There is an edge case for the time before #2639, where the field is empty, but for most current issues that's fine I think.
|
Thanks for the review! I'll do the changes suggested this weekend :) |
fix(queue): update query for faulty rustdoc builds to not assume build status implies anything on the rustdoc result, match on all releases of each crate rather than the latest only, and use the release_build_status table to simplify the query fix(logs): use fields for info! instead of string formatting docs(cratesfyi): clarify usage of command arguments for the new RebuildBrokenNightly command chore(tests): remove unneeded test environment config
Carbonhell
force-pushed
the
feat-cratesfyi-broken-nightlies-rebuilds
branch
from
b7a5f0f to
1be6f5b
Compare
…uild is still in progress with a broken nightly, we'd want it to be included in the list of rebuilds chore(sqlx): run prepare
|
|
github-actions
bot
added
S-waiting-on-deploy
2 participants
Closes #2826 .
This PR adds a cratesfyi CLI command to queue rebuilds for crate versions for which the most recent build failed with a specific nightly version of rustdoc.
The new command allows either passing a single date or a range of dates relative to the nightly version of rustdoc to consider when filtering crates.
The command is scoped under the queue group and it can be executed with:
or:
Start date is inclusive, end date is exclusive and optional. Rebuilds are queued with a lower priority than normal rebuilds (30 vs the default of 20 for normal rebuilds).
I'm not 100% sure whether this is correct: I'm assuming that the nightly version of rustc always matches the version of rustdoc used, as they're shipped together as part of the nightly toolchain. This allows me to use the already existing
rustc_nightly_datefield on the builds table to filter by date.