previously used, and still "logically valid" selectors must not be removed

[yarikoptic]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

• initial zulip discussion link

Yesterday I have mentioned that we merged a PR which was marked green but apparently didn't run any tests although it did in the past: conda-forge/dandi-feedstock#140 (comment) and for a freshly updated PR , where it failed when ran previously, after my changes to recipe it also didn't run at all: conda-forge/datalad-feedstock#130 .

@chrisburr pointed out that

You have skip: true # [py<38] but we no longer support python <3.9 in the global pinning

and in the other (datalad) I had skip: true # [py<39] . After I removed those selectors entirely, PRs started to run tests (and actually identify fails for datalad feedstock, like patches to drop etc)

@beckermr suggested that

We could have the linter fail if there are no ci_support files.

but I think the issue is more "profound": if anyone has a recipe which has a comment instruction to skip for older versions it would silently stop working or require updates (to satisfy linter) whenever the boolean condition is still legit semantically/in principle. I think this would cause unnecessary actions from maintainers which could easily be avoided.

Because ATM it silently allows for packages to pass CI checks and get merged -- I consider it a bug.

Installed packages

N/A

Environment info

N/A

[beckermr]

I think actually there was a mistake by @chrisburr in the logic in the zulip discussion.

If we have a selector skip: true # [py<38], then it skips builds on older pythons. The comment from @chrisburr

You have skip: true # [py<38] but we no longer support python <3.9 in the global pinning

doesn't make any sense since the skip would not activate.

What actually happened here is that azure CI missed a webhook event and the CI never triggered.

We cannot do anything about this ourselves, so there isn't anything for us to do I think.

[yarikoptic]

What actually happened here is that azure CI missed a webhook event and the CI never triggered.

do you mean that it was just some coincidence that multiple repos did not get tested, and then after I pushed removal of those skips , they were?

[beckermr]

yep - azure has these vary odd outages like this

[yarikoptic]

ok, then I guess there is no issue , let's close.