autotick-bot opening unexpected PRs for pre-releases, only sometimes

[mfisher87]

I don't really understand why this is happening, but the autotick-bot is only sometimes opening PRs for pre-releases on this repo: https://github.com/quarto-dev/quarto-cli/releases

Until we got a PR for 1.5.6 a while back, we had never seen a PR for a pre-release. We were especially confused about this because 1.5.6 was an older pre-release at the time. And just now, we got a PR for 1.5.37, which is actually the latest pre-release. But we didn't get any PRs for any pre-releases in between!

It seems to me to be a bug, but I'm not really sure. Thoughts?

On this feedstock, we don't want any PRs for pre-releases.

[beckermr]

The bot judges pre-releases using PEP440 syntax, not github's label. The version tags you are making are not pre-release version tags. See this documentation

https://packaging.python.org/en/latest/specifications/version-specifiers/#pre-release-separators

for how to make a pre-release tag.

I totally, understand if you do not want to change how you tag pre-releases. However, the bot won't be able to handle non-PEP440 pre-releases in all cases, since it uses multiple ways to find versions, including just trying new version numbers in the recipe URLs.

[mfisher87]

Hey @beckermr thanks for your quick response! Unfortunately, I don't have any ownership over the project, I'm just helping get it on Conda Forge :)

That said, I do question this behavior by the autotick bot. Quarto, the project in question, is not a Python project, and I feel leveraging this PEP440-specified definition of pre-release on projects which could be in any language is unintuitive at least. Since we used GitHub, not PyPI, as our release source, I would expect a more language-agnostic behavior here, which is why I assumed pre-releases were identified by the pre-release boolean property of a GitHub Release.

Is there openness to changing this behavior when GitHub Releases are used as the source?

[beckermr]

For sure I am open to it, but I don't think we'll be able to produce a solution that catches all cases.

Note also that pep440 is adopted by conda which packages a lot more than python. So the bot constraint on pre-release versions is not python-specific but is rather conda-specific.

[mfisher87]

Note also that pep440 is adopted by conda which packages a lot more than python. So the bot constraint on pre-release versions is not python-specific but is rather conda-specific.

Ah, TIL. Thanks :)

For sure I am open to it, but I don't think we'll be able to produce a solution that catches all cases.

Yeah, I see what you mean. Having to account for PEP440 no matter the language of the package is a constraint I hadn't considered!

[beckermr]

So I looked at the .atom feed that we use to get github releases and I do not see any pre-release markers in it: https://github.com/quarto-dev/quarto-cli/releases.atom

Thus I don't think we'll be able to address this one at all. :(

[mfisher87]

Oof! What about querying the GitHub Releases API to enrich the data we get from the atom feed? That does contain the pre-release property.

[beckermr]

It likely does but those api requests are very expensive.

[mfisher87]

Expensive enough to rule out the API approach? Or is some experimentation needed to determine that? I'd be happy to help out.

[beckermr]

We have about 35 separate processes running at any given time fetching the latest versions of packages in conda forge. We'd very quickly exhaust any reasonable API limit.

[mfisher87]

👍 Thanks for your time considering.

In light of this, I'd like to disable the autotick bot for this feedstock, as it will only produce undesirable noise and work for me and the other maintainers for ~months until the next actual release. I don't see any way to do this in the docs for conda-forge.yaml. Is there a way?

[beckermr]

Let me look into this. If we don't have an option already I will add one.

[beckermr]

I've opened PR #2646 and will merge it once the tests pass. To enable it on your feedstock, edit the conda-forge.yml file to add the keys

bot:
  version_updates:
    skip: True

It will take a few hours for the feature to go live, so you might get one last PR before then if there is an upstream release already queued up.

[mfisher87]

Amazing, thanks so much @beckermr ! Is there anything I can do to help with updating docs, for example?

[beckermr]

Thank you for the offer! The docs are in conda-smithy unfortunately and we have some restructuring to do. So don't worry about it!

[mfisher87]

Hey @beckermr one more question for you! If we have this skip enable turned on, will @conda-forge-admin, please update version PRs also be disabled? I believe the answer is yes, just wanted to be sure :)

Thanks again for everything!

[beckermr]

That command will NOT be disabled. It runs through a different code base. However, it has to be user initiated so the solution there is simply to not do that.

[mfisher87]

Great, thanks, that's exactly what we needed to know! 🙇