CI: Add more skip conditions #26715
CI: Add more skip conditions #26715
Conversation
52ff0be to
ebb1e86
Compare
|
It seems to me that rather than excluding one-by-one, an approach of exclude-all, and include one-by-one might be better. e.g. |
I think for normal changes to NumPy proper, it would probably be likely that all tests need to run, and that it is probably more rare to want to exclude a bunch of actions. My main motivation was for F2Py, where changes are independent from most of the other tests, but its still less probable, though I might be wrong. |
|
I tend to think that for this to be used often enough to make a dent it needs to be dead simple. Which is a bit related to @melissawm's PR to add My ideal world would be to have maybe 3 different options:
And even better, if we can do it with labels, so you can add it later (at least for possible iterations). In fact, for the "extended tests" I think it would be OK to only enable them with a label, and I think that would actually make a real dent in resource usage. (For docs that would be cool to auto detect obvious docs only changes, but dunno). |
|
Being able to select just one of the jobs, e.g. something like |
|
My [docs only] PR is stalled because it didn't work on my fork and I didn't have time to investigate. If you have a superseding fix please go for it! |
|
In astropy, we do have the "Extra CI" label (which runs |
|
I'll add that I'm not opposed to the change suggested in the PR. The use-case that I described can be achieved with the changes in this PR, so my comment was more about convenience than functionality. |
|
@rgommers also mentioned that a DOC update detailing a simpler workflow (make a fork, enable one workflow, work through it). |
[skip circle] [skip linux] [skip nixblas] [skip sanitizer] [skip musl] [skip qemu] [skip simd] [skip macos] [skip mypy] [skip wingha]
[skip circle] [skip linux] [skip nixblas] [skip sanitizer] [skip musl] [skip qemu] [skip simd] [skip macos] [skip mypy] [skip wingha] [skip azp] [skip cirrus]
Also [skip circle] does the right thing now
[skip linux] [skip wingha] [skip azp] [skip macos] [skip cirrus]
Along with some helpers..
There was a problem hiding this comment.
Can't say much about the whole workflow. I agree with the result (having the options) but I find it hard to find a better/more elegant way to implement it.
I'll add one request: can you add an anchor to the "Commands to skip continuous integration" section @HaoZeke ? I often want to point people here and miss the anchor. Thanks!
| * ``[skip exotic]``: ``[skip quemu] [skip simd] [skip macos] [skip wingha] [skip wasm] [skip musl] [skip circle] [skip azp] [ckip cirrus]`` | ||
| * ``[skip tools]``: Expands to ``[skip codeql] [skip mypy] [skip sanitizer]`` | ||
|
|
||
| Being CI Sensitive |
There was a problem hiding this comment.
My suggestion: maybe this can be an admonition? My only concern is that this maybe too complicated for a regular contributor and we often point them to this section to see the skip commands. Being in an admonition may change the flow of the text so they realize this is more of an advanced workflow.
Spun out of #26708. Might maybe be helpful (post docs) with #24280.
Adds a bunch of tags which can be passed to conditionally disable what isn't needed:
[skip circle][skip linux][skip nixblas][skip sanitizer][skip musl][skip qemu][skip simd][skip macos][skip mypy][skip wingha][wasm skip][codeql skip]Together with a per commit tag, like
[winci f2py](from #26708) these allow for a more fine-grained control over what is run and when. The tags above do not need to be in the first line of the commit, but can occur anywhere in the body of the commit itself. So an all but[winci f2py]commit would look like:Since
[skip azp]can be anywhere in the commit message, but[skip cirrus]must be in the first or last line.