Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow builds of rc-tagged commits #280

Closed
wants to merge 29 commits into from

Conversation

danpetry
Copy link
Contributor

@danpetry danpetry commented Oct 28, 2024

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @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
Copy link
Contributor Author

@conda-forge-admin, please rerender

@conda-forge-admin
Copy link
Contributor

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.

Copy link
Member

@beckermr beckermr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@hmaarrfk
Copy link
Contributor

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
Copy link
Member

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

@danpetry
Copy link
Contributor Author

danpetry commented Oct 29, 2024

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor Author

danpetry commented Oct 29, 2024

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

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

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. 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
Copy link
Contributor Author

danpetry commented Nov 5, 2024

Something like this?

@conda-forge-admin
Copy link
Contributor

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
Copy link
Member

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

@conda-forge-admin , please re-render

@conda-forge-admin
Copy link
Contributor

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.

@jakirkham
Copy link
Member

Do we need to start a new cirun build here?

@h-vetinari
Copy link
Member

Do we need to start a new cirun build here?

#298 is a big PR that's almost complete; I'm going to ask that we prioritize merging that one first.

@jakirkham
Copy link
Member

This is a lightweight PR. Perhaps that makes easier to go in 😉

After all it seems like everyone is already on board here

@h-vetinari
Copy link
Member

It doesn't make it easier, because that PR is a major reshuffle and we shouldn't also layer conflicts with unrelated changes on top (aside from the fact that the CI here is deep red). This PR is more focussed, and will be easier to adapt than vice versa. I can offer to do it even.

@danpetry
Copy link
Contributor Author

danpetry commented Dec 22, 2024

I am fine to wait for that other PR. I am more or less on Christmas break now anyway. I can rebase once it's merged.

@jakirkham
Copy link
Member

Given #298 is now in, can we wrap this one up and merge?

Note CI would pass if someone approved cirun on this PR. Idk that we need it though given the changes already passed on CPU only jobs and nothing here is GPU specific

@danpetry
Copy link
Contributor Author

danpetry commented Jan 7, 2025

Has been re-rendered

Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is functional yet (see below).

As an aside, I think the variable/values are poorly named, if it causes us to write [rc == "rc"]. AFAICT we could just do

rc:
  - True
  - False

and then use # [not rc] and # [rc].

I'm not excited about the duplication of the variant configs, but if people thing this is a net benefit, then so be it.

recipe/meta.yaml Outdated Show resolved Hide resolved
Copy link
Member

@h-vetinari h-vetinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I understood the mechanics now, pretty clever. :)

I've played around with this on a branch and it works as expected. However, please follow the rename below (or simply pick h-vetinari@8f6694a)

recipe/conda_build_config.yaml Outdated Show resolved Hide resolved
@jakirkham
Copy link
Member

FWIW commit ( h-vetinari@8f6694a ) looks reasonable to me

@danpetry
Copy link
Contributor Author

danpetry commented Jan 8, 2025

that's better, thanks

@danpetry
Copy link
Contributor Author

danpetry commented Jan 8, 2025

I've rendered locally but want to see how it goes in the CI, for rc and non-rc

Copy link
Member

@jakirkham jakirkham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Daniel! 🙏

The changes look good

Though let's make sure to go back to a stable version (and re-render) before merging

@@ -1,4 +1,5 @@
{% set version = "2.5.1" %}
# if you wish to build release candidate number X, append the version string with ".rcX"
{% set version = "2.5.1.rc1" %}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{% set version = "2.5.1.rc1" %}
{% set version = "2.5.1" %}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup

@h-vetinari
Copy link
Member

I've picked the changes from this PR into 63779a3, given that 30 commits are a bit much for the core change of

 2 files changed, 26 insertions(+)

😉

Planning to merge this with #305 as soon as CI passes there.

@danpetry
Copy link
Contributor Author

danpetry commented Jan 9, 2025

Cool sounds good. Closing this one, then.

@danpetry danpetry closed this Jan 9, 2025
@danpetry danpetry deleted the rc-builds branch January 9, 2025 22:25
@jakirkham
Copy link
Member

Thanks you both and everyone who helped review! 🙏

@danpetry
Copy link
Contributor Author

danpetry commented Jan 9, 2025

indeed thanks 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants