Soften up-to-date check

jakirkham commented 7 months ago

Currently if conda-smithy is not on the latest version during a rerender, it will raise an error

However if the latest conda-smithy is marked broken, this behavior persists without taking into account the latest non-broken version is older than the latest version naively checked

This can leave bot codes that rerender in a dysfunctional state. Meaning core needs to hunt down and fix these lines at the same time a broken conda-smithy emerges (the exact same time we may not have bandwidth to fix it for the same reason)

Some options we might consider here:

Teach the up-to-date check about broken versions
Soften the up-to-date check to a warning unless a flag is passed to create the error
...?

Please feel free to suggest more

jaimergp commented 7 months ago

Teach the up-to-date check about broken versions

Definitely this. It's a pity that we don't publish the broken label anymore, so I guess we'll have to use the repodata.json sources directly.

jaimergp commented 7 months ago

We can also mark the release as "not latest" in GH? If that's what we are checking.

jakirkham commented 7 months ago

Thinks it is using this logic

https://github.com/conda-forge/conda-smithy/blob/123be4e8d6bd7ffcd7251a7d081a004428d6e388/conda_smithy/configure_feedstock.py#L2191-L2204

We do mark them broken, but they are still under main as well

Do we need to check a different URL than we are using to pick up the repodata patching?

jaimergp commented 7 months ago

I think we can use this variation:

pkg = max(
  [
    f 
    for f in request.json()['files'] 
    if "broken" not in f["labels"]
  ],
  key=lambda x: VersionOrder(x['version']),
)

conda-forge / conda-smithy

Soften up-to-date check #1848