Add toolchain check and crates parameter #23
Conversation
|
|
||
| case "$required_toolchain" in | ||
| nightly) | ||
| if ! echo "$current_toolchain" | grep -q nightly; then |
There was a problem hiding this comment.
In case you like it, claude told me this can be done like this
if [[ "$STRING" == *"world"* ]]; then
echo "contains world"
fiNote: Use *pattern* for literal substring matching.
Or
STRING="hello world"
[[ "$STRING" =~ world ]] && echo "contains world"There was a problem hiding this comment.
Hm, no strong feelings either way. I think I'd roll with one of these if the rest of the script was all bash, but it's kinda all jumbled up right now.
|
utACK b2329b8 |
|
In 5688089: Trailing whitespace. Also, I don't totally buy the "all crates in this repo will have the same MSRV" but I guess we can keep the check until it fails. |
|
At least, we could read the MSRV out of |
|
Other than that 7e4eb32 looks good to me. |
|
def44e0: cleaned up trailing whitespace and tweaked the MSRV toolchain check. I'd prefer to use I find it kinda annoying that a workspace can have crates with different MSRVs. Bit of a mismatch with our tasks here which are currently designed to run for the whole workspace, not a subset of crates. The script does not change the toolchain on the fly and I think it is probably best to keep it this way. One easy option is to get the highest MSRV of all the workspace crates and call that the "effective" MSRV of the workspace. But I went with a more robust approach and just check per-crate, if a caller has multiple MSRVs they deal with running different tasks with the necessary toolchain. |
Yeah I balked at this too, for example I can see the MSRV on the stable crates staying where it is indefinitely while |
|
dfe6fb7: allow passing multiple crate args |
This seems a little weird to me because I assume crates in a workspace are tightly coupled, so bumping the MSRV of one has a high chance of implicitly raising it for the others, but I see the point with primitives/units. Also cargo doesn't enforce any of this so I probably shouldn't assume it. I think the current version of the script supports the case well enough now, the task can be called with a list of crates so a subset on a different MSRV could be tested together. |
nyonson
changed the title
|
I'm fine as it is, we can change it later if we need to. |
|
Closing in favor of xshell #26 |
Well, the "coupling" can only go in one direction (Rust doesn't allow circular dependencies.) So we expect the more "fundamental" crates to have a lower MSRV than the ones that depend on them. |
|
Yea, good point. |
3 participants
The fact that the
stable,nightly, andmsrvtasks were essentially the same was making me twitch a bit, so added toolchain validation to ensure they are being called with the intended toolchain.Added an optional
CRATEarray parameter to run a task on a subset of crates. This allows for things like MSRV checks on crates with different MSRVs in a workspace. It also allows for quick tests on a crate you are hacking on. I believe this is enough to enable some quick and quiet local test cycles.