topherinternational opened a new issue, #41718:
URL: https://github.com/apache/airflow/issues/41718

   ### Apache Airflow version
   
   2.10.0
   
   ### If "Other Airflow 2 version" selected, which one?
   
   _No response_
   
   ### What happened?
   
   In the `Provider checks / Provider packages wheel build and verify` CI test 
task, the command:
   
   `breeze release-management verify-provider-packages --use-packages-from-dist 
--package-format wheel --use-airflow-version wheel 
--airflow-constraints-reference default --providers-constraints-location 
/files/constraints-3.8/constraints-source-providers-3.8.txt` 
   
   installs all of the provider wheels built in the earlier 
   
   `breeze release-management prepare-provider-packages ...` step. 
   
   This process all runs on 3.8 and so implicitly assumes that all of the 
providers are legit for 3.8; neither step looks like it checks 
`excluded-python-versions`. In the best case, this results in testing of a 
provider that wasn't intended to be installed on 3.8. In the case of #41555, a 
provider can't be installed on 3.8 due to package conflicts with an existing 
dependency, so CI fails for the very reason we set the provider to exclude 3.8 
in the first place.
   
   These build and install commands happen in `Provider packages wheel build 
and verify`, and also in  `Compat 2.8.4:P3.8 provider check` and `Compat 
2.9.1:P3.8 provider check`.
   
   So there's a couple of problems:
   * Any providers that are specifically marked not to be used on 3.8 are 
installed during CI, which could cause issues with 3.8-compatible providers or 
their dependencies
   * Providers never get tested for installation on any newer Python versions
   
   I checked the repo and none of the released providers exclude Python 3.8, I 
figure maybe this problem hasn't come up yet.
   
   
   ### What you think should happen instead?
   
   Maybe some options are?
   
   1. Make `prepare-provider-packages` check excluded versions before building 
a particular provider wheel
   2. Add the "Remove incompatible <version> provider packages" stage to 
`Provider packages wheel build and verify`, and have the task reference the 
provider dependencies json and the excluded python versions.
   
   Another thing to consider is whether CI should run the provider checks on 
all supported Airflow Python versions (3.8-3.12) - that would add 16 tasks to 
the CI suite, and validate each provider on every version it claims to be 
installable to.
   
   
   ### How to reproduce
   
   * Take any provider and add `excluded-python-versions = ['3.8']` to the 
provider.yaml
   * Open an airflow project PR with the change to run Github CI
   * Observe the `Provider checks / Provider packages wheel build and verify` 
test task; it will build and install the provider on 3.8 even though the 
provider metadata excludes it from 3.8
   
   
   
   ### Operating System
   
   CI, but repros on OS X
   
   ### Versions of Apache Airflow Providers
   
   _No response_
   
   ### Deployment
   
   Other
   
   ### Deployment details
   
   Github CI
   
   ### Anything else?
   
   _No response_
   
   ### Are you willing to submit PR?
   
   - [X] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of 
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to