Allow builds of rc-tagged commits

danpetry commented 3 weeks ago

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] 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)
[ ] Ensured the license file is being packaged.

Addresses "rc builds" point here
A step towards aligning Anaconda's and conda-forge's recipe
This has been used in the above recipe for a while; suggest disabling the CI, merging, and verifying next time it's needed to conserve resources, but I'm happy with a different approach if desired.

danpetry commented 3 weeks ago

@conda-forge-admin, please rerender

conda-forge-admin commented 3 weeks ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

_{This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11563334896.}

hmaarrfk commented 3 weeks ago

Any rc builds need to go to non-main label.

can we do this with some kind of "jinja" syntax? i don't think so right?

beckermr commented 3 weeks ago

I think it might be able to zip in the channel config in the conda build config.

danpetry commented 3 weeks ago

Are you thinking something like this?

channel_targets:
  - conda-forge main
  - conda-forge rc
rc:
  - none
  - 5
zip_keys:
  -
    - channel_targets
    - rc

I don't think you'd want to build a release candidate and a normal release in parallel, though. I can't see a way to make channel_targets conditional, since it needs to be in the cbc.yaml.

What are your requirements around this in general? We use it to prepare for the main release and reduce latency between upstream and the conda package. We don't upload the rc packages.

Hi from oak park 👋

beckermr commented 3 weeks ago

Hi from oak park too!

Yeah I am ok building them in parallel.

You can also use a branch on the feedstock and only rebuild rcs periodically.

danpetry commented 3 weeks ago

Just to clarify, I don't need rc builds on conda-forge's channel, personally. What I'm trying to do here is to align Anaconda's recipe with your recipe to foster closer collaboration and pool resources. I spotted the point about rc builds in this issue and thought this feature would be a good place to start.

With that said, happy to contribute the previous code suggestion if it fits your needs.

danpetry commented 3 weeks ago

Are you thinking to make the rcs public? I think by the time we get an rc for a certain release building, the proper release will be pretty close if not already happened, so users will just want the proper release instead?

hmaarrfk commented 3 weeks ago

You can also use a branch on the feedstock and only rebuild rcs periodically.

Generally speaking this was my intention, somebody could keep a "1 commit PR" alive for referring to periodically.

trimmed down build matrix for reduced resource use and whatnot.

jakirkham commented 3 weeks ago

Matt is referring to CFEP 5, which spells out how we handle RCs

It could be useful to have RCs to test that upstream changes build ok here or perhaps test combinations of packages locally

Typically we do a branch for RCs, but that sounds like a lot of effort to maintain here

Perhaps we could do the matrix approach and just add a skip that ignores the stable or RC build depending on the version specified. That way there should be no additional builds and it would be pretty easy to flip on/off

conda-forge-admin commented 2 weeks ago

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

conda-forge-admin commented 2 weeks ago

Hi! This is the friendly automated conda-forge-linting service.

I failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory.

_{This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11693957062.}

danpetry commented 2 weeks ago

Something like this?

conda-forge-admin commented 2 weeks ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

jakirkham commented 2 weeks ago

Seems like a good starting point. Let's try re-rendering

@conda-forge-admin , please re-render

conda-forge-admin commented 2 weeks ago

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

conda-forge-admin commented 2 weeks ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

danpetry commented 2 days ago

This seems to work correctly for non-rc:

channel_targets:
- conda-forge main
...
rc:
- None

osx_64 is building.

Will switch to an rc build and see what the config and git fetching looks like.

jakirkham commented 2 days ago

Also will want to re-render for the last change to take effect

danpetry commented 2 days ago

@conda-forge-admin please re-render

danpetry commented 2 days ago

thanks

danpetry commented 2 days ago

I probably want to add something to the build string too

jakirkham commented 2 days ago

I probably want to add something to the build string too

Wouldn't the version already capture this for us? What else would we want to include?

danpetry commented 1 day ago

yep, that would be better

danpetry commented 1 day ago

The rc is looking good

channel_targets:
- conda-forge pytorch_rc
...
rc:
- rc
...
checkout: 'v2.5.1-rc1'

and building

conda-forge-admin commented 1 day ago

Hi! This is the friendly automated conda-forge-linting service.

I failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory.

_{This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11943959572.}

jakirkham commented 22 hours ago

This seems pretty good. Thanks for working on this Dan! 🙏

Would be interested to hear from others on this change 🙂

conda-forge / pytorch-cpu-feedstock

Allow builds of rc-tagged commits #280