Fix scheduled CI upgrade job: extract versions from uv.lock + Slack alerts

[potiuk]

Fixes the scheduled [v3-2-test] Scheduled CI upgrade check job (and the equivalent main schedule) and makes both runs observable via Slack.

Why it was failing

breeze ci upgrade was rewriting hard-coded uv / prek version strings inside .github/workflows/*.yml files. The default GITHUB_TOKEN used by the scheduled job is a GitHub App token and is not permitted to push changes to workflow files, so the push was rejected with:

refusing to allow a GitHub App to create or update workflow .github/workflows/basic-tests.yml without workflows permission

Rather than add a PAT or a dedicated GitHub App just to patch a version string, this PR removes the reason those files need patching at all.

Extract versions from uv.lock

All CI workflows and composite actions now read uv (and prek where needed) at runtime from uv.lock using a tiny sed snippet:

sed -n '/^name = "uv"$/{n;s/^version = "\(.*\)"$/\1/p;}' uv.lock

The uv.lock format is stable — the line immediately after name = "<pkg>" is version = "<X.Y.Z>" for that package — so this is a safe, dependency-free extraction with a loud failure if it ever returns empty. uv lock --upgrade already runs as part of the same scheduled upgrade, so lockfile bumps keep flowing through automatically.

Files touched:

• .github/actions/breeze/action.yml, .github/actions/install-prek/action.yml — extract UV_VERSION (and PREK_VERSION for install-prek) in an early step, expose them as step outputs, and wire them into the install steps' env: blocks and both cache-key expressions. Removed the now-unused uv-version / prek-version inputs.
• .github/workflows/basic-tests.yml — dropped the uv-version workflow input; each Install uv step extracts inline from uv.lock.
• .github/workflows/scheduled-verify-release-calendar.yml, .github/workflows/ci-amd-arm.yml, .github/workflows/update-constraints-on-push.yml — removed top-level UV_VERSION env vars; inline extraction in the install step where one was used.
• .github/workflows/release_dockerhub_image.yml — removed with: uv-version: ${{ env.UV_VERSION }} (the env var was dangling anyway).
• scripts/ci/prek/upgrade_important_versions.py — removed the workflow / action YAML paths from FILES_TO_UPDATE; they no longer carry hard-coded versions to patch.

Net effect: breeze ci upgrade no longer touches any file under .github/workflows/*, so the scheduled upgrade job can push its PR using only the default GITHUB_TOKEN.

Slack notifications (#internal-airflow-ci-cd)

.github/workflows/upgrade-check.yml now posts on both success and failure:

• Success — fires when a new CI upgrade PR exists. Message links to the PR and includes numbered steps:
  1. Undraft the PR to trigger CI
  2. Review the changes
  3. Merge it once CI passes
• Failure (if: failure()) — fires if breeze ci upgrade or any earlier step in the job fails. Links directly to the failed run so on-call can investigate and re-run.

The branch prefix ([main] vs [v3-2-test]) distinguishes notifications between the two schedules.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.6)

Generated-by: Claude Code (Opus 4.6) following the guidelines

[github-actions]

Backport failed to create: v3-2-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-2-test

You can attempt to backport this manually by running:

cherry_picker c66d540 v3-2-test

This should apply the commit to the v3-2-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.