Skip to content

Fail prod image release when constraint build fails - #62387

Merged
potiuk merged 1 commit into
mainfrom
fail-to-release-image-when-constraints-build-fail
Feb 24, 2026
Merged

Fail prod image release when constraint build fails#62387
potiuk merged 1 commit into
mainfrom
fail-to-release-image-when-constraints-build-fail

Conversation

@potiuk

@potiuk potiuk commented Feb 23, 2026

Copy link
Copy Markdown
Member

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?
  • Yes (please specify the tool below)

  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

@potiuk potiuk added the _eol_backport-to-v2-11-test Mark PR with this label to backport to v2-11-test branch label Feb 23, 2026
@potiuk

potiuk commented Feb 23, 2026

Copy link
Copy Markdown
Member Author

I will still need to test it a bit more

@potiuk
potiuk force-pushed the fail-to-release-image-when-constraints-build-fail branch from a817b88 to 364f71f Compare February 23, 2026 22:53
@potiuk potiuk added the full tests needed We need to run full set of tests for this PR to merge label Feb 23, 2026
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
@potiuk
potiuk force-pushed the fail-to-release-image-when-constraints-build-fail branch from 364f71f to 1ac6f0e Compare February 23, 2026 22:54
@potiuk

potiuk commented Feb 23, 2026

Copy link
Copy Markdown
Member Author

Ok. Should be good :)

@potiuk
potiuk merged commit 62121a0 into main Feb 24, 2026
129 checks passed
@potiuk
potiuk deleted the fail-to-release-image-when-constraints-build-fail branch February 24, 2026 05:43
@github-actions

Copy link
Copy Markdown
Contributor

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status Branch Result
v3-1-test Commit Link

You can attempt to backport this manually by running:

cherry_picker 62121a0 v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

@github-actions

Copy link
Copy Markdown
Contributor

Backport failed to create: v2-11-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status Branch Result
v2-11-test Commit Link

You can attempt to backport this manually by running:

cherry_picker 62121a0 v2-11-test

This should apply the commit to the v2-11-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

potiuk added a commit to potiuk/airflow that referenced this pull request Mar 4, 2026
…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
potiuk added a commit that referenced this pull request Mar 4, 2026
…) (#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
@potiuk potiuk added this to the Airflow 3.1.8 milestone Mar 4, 2026
potiuk added a commit to potiuk/airflow that referenced this pull request Mar 4, 2026
…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
potiuk added a commit to potiuk/airflow that referenced this pull request Mar 4, 2026
…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
potiuk added a commit that referenced this pull request Mar 4, 2026
) (#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
vatsrahul1001 pushed a commit that referenced this pull request Mar 4, 2026
…) (#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
dominikhei pushed a commit to dominikhei/airflow that referenced this pull request Mar 11, 2026
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
Ankurdeewan pushed a commit to Ankurdeewan/airflow that referenced this pull request Mar 15, 2026
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:dev-tools area:production-image Production image improvements and fixes _eol_backport-to-v2-11-test Mark PR with this label to backport to v2-11-test branch full tests needed We need to run full set of tests for this PR to merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Do not fallback to "no-constraints" in release PROD image builds

3 participants