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

Providers requirements for every python version #35086

Conversation

pierrejeambrun
Copy link
Member

@pierrejeambrun pierrejeambrun commented Oct 20, 2023

Allow to generate providers requirements for all python versions. Use all python versions compatible with the associated_airflow_version of the provider.

Parallelize image building for different python versions (images with all the airflow versions pre-installed)

Update the output file structure to look like this:
image

@pierrejeambrun pierrejeambrun force-pushed the providers-requirements-for-every-python-version branch 2 times, most recently from 318fbd8 to a21f956 Compare October 20, 2023 15:54
@potiuk
Copy link
Member

potiuk commented Oct 20, 2023

Comment 1: It takes a long time to build the images with all the airflow versions in but we can optimize it later by pushing them to ghcr.io and using them as cache (should be separate step).

@potiuk
Copy link
Member

potiuk commented Oct 21, 2023

All looks good I have just a few general comments (and some improvement proposals / test results will come as inline comments).

  1. We will need this "all-airflow" images only once to generate all historical versions of providers. But we might find some errors/problems/need to regenerate those so we should keep it. I already have the cache built on my local machine too, so I might push them to our ghcr.io repo and pull rather than rebuild them. I can make some comments on how this can be done easily @pierrejeambrun (might be useful to learn how caching works) - or I can do it as a follow-up PR as you wish, let me know:).

  2. Later when we turn it into "generate requirements for the last wave of providers only" the default should be to use the "latest release image" for those tests only - but we should add such capability as separate PR.

@pierrejeambrun
Copy link
Member Author

Thank you for the reviews.

I agree, both updating the release process and image caching are important and should be done in follow up steps.

@potiuk I will address the other comments and do the image caching as a follow up right after. Seems cool to do and I would like to give it a try, I'll let you know if I need some help :)

@pierrejeambrun pierrejeambrun force-pushed the providers-requirements-for-every-python-version branch from 05f0107 to ec78617 Compare October 22, 2023 18:18
Copy link
Member

@potiuk potiuk left a comment

Choose a reason for hiding this comment

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

Looks fantastic :)

@pierrejeambrun pierrejeambrun force-pushed the providers-requirements-for-every-python-version branch 2 times, most recently from b76f3f1 to da1cc5b Compare October 22, 2023 21:15
@pierrejeambrun
Copy link
Member Author

pierrejeambrun commented Oct 22, 2023

Made a few adjustments to allow for more flexibility in the provider_ids/provider_versions combo.

This way we can:

  • Regenerate requirements for all historical versions of a specific provider, (or all providers)
  • Regenerate requirements for latest versions of a specific provider (or all providers -> release wave)
  • Regenerate requirements for a specific provider and version

@pierrejeambrun pierrejeambrun force-pushed the providers-requirements-for-every-python-version branch 2 times, most recently from c5f37ec to 9541638 Compare October 22, 2023 21:25
@pierrejeambrun pierrejeambrun force-pushed the providers-requirements-for-every-python-version branch from 9541638 to 06da7cc Compare October 23, 2023 11:26
@potiuk
Copy link
Member

potiuk commented Oct 23, 2023

Made a few adjustments to allow for more flexibility in the provider_ids/provider_versions combo.

This way we can:

  • Regenerate requirements for all historical versions of a specific provider, (or all providers)
  • Regenerate requirements for latest versions of a specific provider (or all providers -> release wave)
  • Regenerate requirements for a specific provider and version

Whoa. Let me take a look.

Copy link
Member

@potiuk potiuk left a comment

Choose a reason for hiding this comment

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

Yeah. That looks really good and flexible to handle both initial generation and regular. Only a small NIT.

@potiuk
Copy link
Member

potiuk commented Oct 23, 2023

Images need to be regenerated after my changes :(

@pierrejeambrun pierrejeambrun force-pushed the providers-requirements-for-every-python-version branch from e00f6fd to 7719593 Compare October 23, 2023 22:25
@pierrejeambrun pierrejeambrun merged commit 3fa75e9 into apache:main Oct 24, 2023
@pierrejeambrun pierrejeambrun deleted the providers-requirements-for-every-python-version branch October 24, 2023 08:12
potiuk pushed a commit that referenced this pull request Oct 29, 2023
* Restructure output directory to handle multiple python versions

* Generate for all historical versions

* Add output to parallel mode

* Split all airflow images building to a separate command

* Allow generating per provider requirements

* Update parameters help description

(cherry picked from commit 3fa75e9)
@potiuk potiuk added the changelog:skip Changes that should be skipped from the changelog (CI, tests, etc..) label Oct 29, 2023
@potiuk potiuk added this to the Airflow 2.7.3 milestone Oct 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:dev-tools changelog:skip Changes that should be skipped from the changelog (CI, tests, etc..)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants