[ci skip] ***NO_CI*** [skip ci] Disable autotick bot for now

[mfisher87]

We were receiving PRs for Quarto pre-releases, and this is expected behavior of the bot for now.

A "skip" feature was generously added for us to quiet down those bot PRs.

See: https://github.com/regro/cf-scripts/issues/2642

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed) -- I think I don't need to do this because of ci skip, right?
• [ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[cderv]

Oh thanks for looking into that !

[cderv]

I read the issue there and learnt about the PEP version specification. https://packaging.python.org/en/latest/specifications/version-specifiers/#pre-releases

This is interesting; We did not consider really some markers specific for pre-release. We only rely on the pre-release status from Github Release;

Even semver are supposed to follow another syntax that we use https://semver.org/spec/v2.0.0.html#spec-item-9

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--.

Maybe we should consider improving our numbering toward a known standard.

Anyhow, regarding this autotick bot problem, I have another automated suggestion. This would still add noise, but we could also do the following on this repo side, with a specific workflow

• When a PR is open, check if this is auto tick bot
• We check the latest version information on quarto.org
• If the PR is about new pre-release, with close the PR from the workflow.
• Otherwise we leave it open

We have notification noise, but we don't have to deal with the closing ourself.

Otherwise, if you deactivate auto tick bot, is there a way to trigger it manually ? Because we could also

• Either have a workflow in here, that check for a new release on quarto.org and tricker a PR for update
• Either have a workflow call from quarto-dev/quarto-cli, that would trigger an action in this repo when we do a new release on quarto-cli repo.

I can help setup all this. I just don't know much about this autotick bot and what it means really to opting out completely

[mfisher87]

Maybe we should consider improving our numbering toward a known standard.

I like this :) I think that's probably the best way forward, so users don't need additional context to identify a pre-release (conda forge or not)!

Anyhow, regarding this autotick bot problem, I have another automated suggestion. This would still add noise, but we could also do the following on this repo side, with a specific workflow

I'm not sure what the policy is on adding custom workflows to a feedstock repo, I've never seen it before! But I see there's value there. Maybe will raise it on the Conda Forge Element chat and see what folks think.

Otherwise, if you deactivate auto tick bot, is there a way to trigger it manually ?

@conda-forge-admin, please update version

is the usual way, but we can't specify which version to update to. So it may still pull a pre-release. What I'm unsure about is whether our config to "skip" the bot will also skip those manually-requested bot runs. I'll ask over in the other thread.

Because full releases of Quarto come out fairly infrequently compared to pre-releases, I think the burden to manually opening the PRs isn't too bad, at least until we have a way to identify pre-releases from the version number. What do you think?

[cderv]

Because full releases of Quarto come out fairly infrequently compared to pre-releases, I think the burden to manually opening the PRs isn't too bad, at least until we have a way to identify pre-releases from the version number. What do you think?

Of definitely. We do a release process already for other venu (like Chocolatey build). And I trigger a manual build in the bundle repo once in a while after a release.

So we can definitely do the same here. It would be even easier if we can trigger it easily using a workflow_dispatch or a comment somewhere. Not locally doing change to create a PR. But still ok !

So definitely a good enough solution to me.