amoghrajesh opened a new pull request, #76593:
URL: https://github.com/apache/airflow/pull/76593
<!-- SPDX-License-Identifier: Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0 -->
<!--
Thank you for contributing!
Please provide above a brief description of the changes made in this pull
request.
Write a good git commit message following this guide:
https://chris.beams.io/posts/git-commit/
Please make sure that your code changes are covered with tests.
And in case of new features or big changes remember to adjust the
documentation.
For user-facing UI changes, please attach before/after screenshots (or a
short
screen recording) so reviewers can assess the visual impact.
Feel free to ping (in general) for the review if you do not see reaction for
a few days
(72 Hours is the minimum reaction time you can expect from volunteers) - we
sometimes miss notifications.
In case of an existing issue, reference it using one of the following:
* closes: #ISSUE
* related: #ISSUE
-->
---
##### Was generative AI tooling used to co-author this PR?
<!--
If generative AI tooling has been used in the process of authoring this PR,
please
change below checkbox to `[X]` followed by the name of the tool, uncomment
the "Generated-by".
-->
- [ ] Yes (please specify the tool below)
<!--
Generated-by: [Tool Name] following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
-->
The `release-constraints` workflow refuses to resolve constraints for a
final while any provider's newest PyPI version is a release candidate (#75919).
In `start-release` that workflow runs only after the artifacts are committed to
SVN and uploaded to PyPI. When the check trips there, the final is already on
PyPI with no constraints, and the upload cannot be undone.
This runs the same check at the start of `breeze release-management
start-release`, before the SVN clone. A "ready" provider whose newest non
yanked PyPI version is a pre release now stops the release before anything
irreversible happens. The output lists the providers and tells the release
manager to release or yank each candidate.
The check mirrors `build_pinned_provider_requirements` in
`run_generate_constraints.py`, so both places agree on what "pending" means.
The workflow guard stays as it is and still covers anything published in
between.
related: #75919, #76592
#76592 adds a way to override the workflow guard. If it merges, this early
check should offer the same override as a prompt, so the release manager is
asked only when candidates are actually pending, not on every release. I can do
that in whichever PR lands second.
Tests: `uv run pytest dev/breeze/tests/test_release_constraints.py
dev/breeze/tests/test_release_command.py` (36 passed). The ordering test fails
without the change to `release_command.py`.
---
* Read the **[Pull Request
Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#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](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals))
is needed.
* When adding dependency, check compliance with the [ASF 3rd Party License
Policy](https://www.apache.org/legal/resolved.html#category-x).
* For significant user-facing changes create newsfragment:
`{pr_number}.significant.rst`, in
[airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments).
You can add this file in a follow-up commit after the PR is created so you
know the PR number.
--
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]
