publish-docs-to-s3 fails on tags cut before #66100

[potiuk]

Issue

.github/workflows/publish-docs-to-s3.yml runs
python3 dev/registry/derive_wave_providers.py unconditionally in the
Build Info job. The script was introduced by #66100 (commit
b5e9bae6dc, 2026-04-30). Any release tag cut before that commit does
not contain the script, so the docs publish workflow fails at this
step when invoked on those tags.

Hit while publishing docs for airflow-ctl/0.1.4 (cut from
0.1.4rc3 on 2026-04-22). The Build Info job failed with:

python3: can't open file '.../dev/registry/derive_wave_providers.py': [Errno 2] No such file or directory
##[error]Process completed with exit code 2.

Failed runs:

• https://github.com/apache/airflow/actions/runs/25392730378
  (workflow on main, --ref airflow-ctl/0.1.4)
• https://github.com/apache/airflow/actions/runs/25392898972
  (same, with --apply-commits b5e9bae6dc — --apply-commits runs in
  a later job, doesn't reach the Build Info failure point)

Workaround

Pass --workflow-branch <release-tag> so the workflow YAML at the
tag is used (the workflow at the tag predates the registry-derive
step):

breeze workflow-run publish-docs \
  --ref airflow-ctl/0.1.4 \
  --workflow-branch airflow-ctl/0.1.4 \
  apache-airflow-ctl

That run: https://github.com/apache/airflow/actions/runs/25393124890

Fix options

1. Wrap the registry-derive step in
   if: hashFiles('dev/registry/derive_wave_providers.py') != ''
   (or guard the run: block with [ -f ... ] && python3 ...).
   Lowest-churn fix; lets old tags publish docs with the current
   workflow definition.
2. Skip the registry-derive step entirely for non-provider
   distributions (airflow-ctl, helm-chart, etc.) — the registry
   rebuild is provider-targeted, so it's a no-op for these anyway.
3. Cherry-pick the script onto release branches during release prep.
   Higher friction; doesn't help for tags already cut.

Scope

Any tag predating b5e9bae6dc on the workflow branch — anyone
republishing docs for an older release (e.g. a fix backport on an
older provider release) will hit this. Workaround is universal but
adds a release-manager footgun.

---

Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting