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

dev pip-compile: switch devel branch pip-compile to 3.11 #1616

Merged
merged 2 commits into from
Aug 20, 2024

Conversation

gotmax23
Copy link
Collaborator

This adjusts the devel branch to use Python 3.11 to generate
dependencies with pip-compile. This also adjusts the pip-compile-dev
workflow to run separate jobs for the stable branches, which will still
use Python 3.10 for requirements files. It's not a very
DRY approach; Github Actions does not support loops.

Fixes: #1614
Fixes: #1450

@gotmax23 gotmax23 added no_backport This PR should not be backported. devel only. tooling This PR affects tooling (CI, pr_labeler, noxfile, linters, etc.) but not the docs builds themselves. labels Jun 19, 2024
@oraNod oraNod requested review from webknjaz and oraNod June 20, 2024 09:44
Copy link
Contributor

@oraNod oraNod left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for the changes @gotmax23 🚀

@webknjaz
Copy link
Member

webknjaz commented Jun 24, 2024

It's not a very
DRY approach; Github Actions does not support loops.

That's not really true: you can have a matrix definition that calls a reusable workflow and passes matrix factors in. This does work, both me and Don have used this approach in the past.

UPD: What doesn't work is skipping some jobs in an event-dependent manner with just declarative syntax. This can be solved by a separate job that pre-computes the matrix, though.

@gotmax23
Copy link
Collaborator Author

you can have a matrix definition that calls a reusable workflow

That's true. I'm not sure why I completely forgot about matrices. I'll try to refactor this.

@oraNod oraNod self-requested a review June 25, 2024 09:01
@gotmax23
Copy link
Collaborator Author

gotmax23 commented Jul 6, 2024

I'll work on this later this month, after I get back from vacation.

@gotmax23 gotmax23 marked this pull request as draft July 6, 2024 04:48
@oraNod
Copy link
Contributor

oraNod commented Aug 6, 2024

@gotmax23 Hello. Friendly reminder on this PR. Do you think you'd have some time to look at refactoring this? Maybe it's not that big of a deal but I think it'd be nice to bump to 3.11 fairly soon so there's plenty of time before 2.18 etc. Cheers!

@gotmax23
Copy link
Collaborator Author

Thanks for the ping. I'm back from Flock to Fedora, so I should have a draft ready early this week. I'm thinking that allowing manual triggering with custom input makes this too complicated, so I think I'll remove that part and make this into a more simple matrix that runs on a scheduled basis and can also be triggered all at once with the default (hard-coded) inputs.

This adjusts the devel branch to use Python 3.11 to generate
dependencies with pip-compile. This also adjusts the pip-compile-dev
workflow to run separate jobs for the stable branches, which will still
use Python 3.10 for requirements files.

Fixes: ansible#1614
Fixes: ansible#1450
@gotmax23 gotmax23 force-pushed the new-pip-compile-311 branch from b9485eb to 12ffd4b Compare August 13, 2024 17:28
@gotmax23 gotmax23 marked this pull request as ready for review August 13, 2024 17:29
@gotmax23
Copy link
Collaborator Author

This is ready for review now.

@gotmax23
Copy link
Collaborator Author

@oraNod oraNod requested a review from samccann August 19, 2024 14:49
Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <[email protected]>
Copy link
Contributor

@oraNod oraNod left a comment

Choose a reason for hiding this comment

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

Thanks for doing this @gotmax23 I think it looks good and can see that it works from the run that you did off your branch.

I've added @samccann as a reviewer mainly as an FYI because this is something we'll need to maintain every time we cut a new branch etc. I can start documenting these things as well as the different Python versions in the README in the next week or so. We have some scribble notes but should probably convert those to something other folks can work with.

@oraNod
Copy link
Contributor

oraNod commented Aug 20, 2024

@gotmax23 I also like the fact it's not too complicated. I guess you probably could get rid of some repetition and make it fancy but I feel like that might make it harder for folks to grok and could put off maintainers. Thanks again.

@gotmax23
Copy link
Collaborator Author

I also like the fact it's not too complicated. I guess you probably could get rid of some repetition and make it fancy but I feel like that might make it harder for folks to grok and could put off maintainers.

We could use YAML anchors or something to reuse the nox-args values (one anchor for Python 3.11 + the devel-only tag script and one for Python 3.10) or automatically generate pr-branch based on base-branch, but yeah, that adds extra complexity and I think what we have is pretty maintainable.

I'll merge this now and we can always iterate on this further as needed. I opened a separate issue to create the necessary documentation that you mentioned.

@gotmax23 gotmax23 merged commit e38e2c5 into ansible:devel Aug 20, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no_backport This PR should not be backported. devel only. tooling This PR affects tooling (CI, pr_labeler, noxfile, linters, etc.) but not the docs builds themselves.
Projects
None yet
3 participants