Fail prod image release when constraint build fails - #62387
Conversation
|
I will still need to test it a bit more |
a817b88 to
364f71f
Compare
When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 Closes: #62349
364f71f to
1ac6f0e
Compare
|
Ok. Should be good :) |
Backport failed to create: v3-1-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 62121a0 v3-1-testThis should apply the commit to the v3-1-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
Backport failed to create: v2-11-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 62121a0 v2-11-testThis should apply the commit to the v2-11-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
…he#62387) When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 (cherry picked from commit 62121a0) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Closes: apache#62349
…) (#62833) When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 (cherry picked from commit 62121a0) Closes: #62349
…che#62387) When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 (cherry picked from commit 62121a0) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Closes: apache#62349
…che#62387) When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 (cherry picked from commit 62121a0) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Closes: apache#62349
) (#62837) When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 (cherry picked from commit 62121a0) Closes: #62349
…) (#62833) When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 (cherry picked from commit 62121a0) Closes: #62349
When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 Closes: apache#62349
When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting. This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061 Closes: apache#62349
When constraint build fails, building prod and ci image by default fall back to "no-constraints" build in order to account for newly added or modified dependencies that conflict with constraints, however in case of release build, such fallback should not happen - simply the build should fail if constraints are conflicting.
This avoids the case that we had with virtualenv being removed from PyPI pypa/virtualenv#3061
Closes: #62349
Was generative AI tooling used to co-author this PR?
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.