The GitHub Actions job "uv in /., /airflow-core, /airflow-ctl, 
/providers/informatica/dev/informatica_simulator, /task-sdk for cryptography - 
Update #1505299371" on airflow.git/main has failed.
Run started by GitHub user dependabot[bot] (triggered by dependabot[bot]).

Head commit for run:
26d53bd1e84088bf7cb7ab11dcfde3d8e6b99048 / Jarek Potiuk <[email protected]>
Resolve the constraints a release ships instead of tagging whatever exists 
(#71040)

* Resolve the constraints a release ships instead of tagging whatever exists

The constraints published with a version were whatever the constraints-X-Y
branch happened to hold when the release ran - a resolution made by the last CI
build, for the sources at that moment, rather than for the version being
released. The candidate tagged that tip and the final release retagged the
candidate, so no release ever resolved constraints of its own.

A candidate now resolves them allowing pre-releases: the providers of the wave
being voted on exist on PyPI only as rc versions, so constraints that refuse
pre-releases cannot describe what a tester is asked to install. They land on a
branch of the candidate's own, leaving the branch every other build reads where
it was. The final release cannot promote those by retagging - a released version
must never pin an rc - so it resolves the same set again, without pre-releases,
and commits onto constraints-X-Y, which is what makes the released constraints
the baseline everything downstream reads.

Which of the two happens is derived from the version, so the stage cannot be set
inconsistently with it. The work runs on CI runners rather than on the release
manager's machine, which would otherwise need a CI image for every supported
Python before it could cut a release, and is reachable on its own through
`breeze workflow-run release-constraints` for redoing a candidate's constraints
or producing them for a release cut before this existed.

* Let only the providers answer with a pre-release

`--pre` applies to the whole resolution, so a candidate's constraints could pin
a pre-release of any dependency - a beta of some third-party library would end
up in what a release ships, which is not what allowing rc providers was meant to
permit. uv considers a pre-release for a package only when a requirement for it
mentions one, so naming the providers with a pre-release lower bound confines
the allowance to them and leaves every other package on the default policy.

* State the pre-release scoping rather than leaning on uv's default

The rc lower bounds already confined pre-releases to the providers, but only
because uv's default strategy happens to permit them for explicitly marked
packages. Naming `explicit` says that in the command instead of leaving it to a
default that could change, and drops the `if-necessary` half of that default -
the part that would let a package nobody marked resolve to a pre-release when no
final version satisfies it.

* Document what a release manager now sees at the constraints step

The candidate half was undocumented - the release notes described only what the
final release does, leaving a release manager to infer why a candidate suddenly
grows a branch and a tag of its own, and why its constraints pin rc providers
when nothing else in them is a pre-release. Both stages and the scope of the
pre-release allowance are stated where each is reached.

* Register the new constraints command where the docs checks look for it

A command has to be grouped in its `*_commands_config.py` and embedded in one of
the breeze docs, or the static checks reject it - `--allow-pre-releases` had no
group and `workflow-run release-constraints` had a generated screenshot that
nothing referenced. The two `setup` screenshots move because the command list
they render is exactly what gained the new entry.

Report URL: https://github.com/apache/airflow/actions/runs/30898218829

With regards,
GitHub Actions via GitBox


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to