Always upgrade to newer dependencies in main#17939
Conversation
When we want to run the "push" or "schedule" build, we want to always "upgrade to newer dependencies" because we want to attempt to generate latest constraints. There was a mistake that caused failures like celery incompatibilities because successfull main build pushed downgraded constraints because the released image did not contain latest celery libraries and it has not been rebuilt with latest constraints yet.
|
This was the root cause of the problems like https://github.com/apache/airflow/pull/17935/checks?check_run_id=3471093531#step:10:5138 which happened recently from time to time. The problem was that successful build in main could actually "Downgrade" the constraints in some cases where cached image contained still celery 4.7. This one should fix it - all the "main" (push/schedule) builds will use the "eager upgrade" and the generated constraints will never be downgraded to the last cache. |
|
The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease. |
The apache#17939 did not fix the problem finally. It turned out that one more change was needed - since we now always upgrade to latest dependencies in `push` and `schedule` type of build we do not need to check for the variable UPGRADE_TO_NEWER_DEPENDENCIES (which was not set in "Build Image" step. This fixes it, but also changes the constraint generation to add comments in the generated constraint files, describing how and why the files are generated.
The apache#17939 did not fix the problem finally. It turned out that one more change was needed - since we now always upgrade to latest dependencies in `push` and `schedule` type of build we do not need to check for the variable UPGRADE_TO_NEWER_DEPENDENCIES (which was not set in "Build Image" step. This fixes it, but also changes the constraint generation to add comments in the generated constraint files, describing how and why the files are generated.
The #17939 did not fix the problem finally. It turned out that one more change was needed - since we now always upgrade to latest dependencies in `push` and `schedule` type of build we do not need to check for the variable UPGRADE_TO_NEWER_DEPENDENCIES (which was not set in "Build Image" step. This fixes it, but also changes the constraint generation to add comments in the generated constraint files, describing how and why the files are generated.
The #17939 did not fix the problem finally. It turned out that one more change was needed - since we now always upgrade to latest dependencies in `push` and `schedule` type of build we do not need to check for the variable UPGRADE_TO_NEWER_DEPENDENCIES (which was not set in "Build Image" step. This fixes it, but also changes the constraint generation to add comments in the generated constraint files, describing how and why the files are generated. (cherry picked from commit bec006e)
When we want to run the "push" or "schedule" build, we want
to always "upgrade to newer dependencies" because we want to
attempt to generate latest constraints.
There was a mistake that caused failures like celery
incompatibilities because successfull main build pushed downgraded
constraints because the released image did not contain latest
celery libraries and it has not been rebuilt with latest
constraints yet.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.