shahar1 opened a new issue, #74114:
URL: https://github.com/apache/airflow/issues/74114
### Body
`breeze workflow-run sync-staging-to-main` force-updates the `staging`
branches of `apache/airflow-site` and `apache/airflow-site-archive` to `main`
by dispatching the `reset-staging.yml` workflow in both repositories. The only
guard today is a yes/no confirmation prompt ("Is no other release vote in
progress, and should staging be reset to main?"). That is too brittle: a
release manager who answers "yes" out of habit silently drops everything that
was only on `staging`, including docs staged for another release vote that is
still in progress.
Neither side detects the situation it warns about:
- `workflow_run_sync_staging_to_main` in
`dev/breeze/src/airflow_breeze/commands/workflow_commands.py` does not look at
the branches at all. It prints a warning, asks for confirmation, and triggers
the workflows.
- `reset-staging.yml` in both site repositories compares the `main` and
`staging` SHAs, but only to skip the push when they are already equal. Any
other deviation is force-pushed over.
### What is needed
Add a locking mechanism so that an existing deviation between `staging` and
`main` has to be acknowledged explicitly, on top of the current confirmation
prompt:
1. Before triggering the workflows, breeze should compare `staging` against
`main` in each repository (for example via `gh api
repos/<repo>/git/ref/heads/<branch>` or `gh api
repos/<repo>/compare/main...staging`, so no clone is needed).
2. If `staging` is already at `main`, or is strictly behind it, proceed as
today.
3. If `staging` has commits that are not on `main`, print those commits (SHA
and subject at least) for each affected repository and refuse to trigger the
workflow unless an explicit acknowledgement flag was passed (for example
`--acknowledge-staging-changes` or `--force`). The flag is required in addition
to the existing confirmation prompt, and `--answer yes` alone must not satisfy
it.
4. Optionally, pass the observed `staging` SHA to the workflow as an input
and have `reset-staging.yml` refuse to run if `staging` moved since breeze
inspected it, so the check cannot race with a concurrent docs publish.
Documentation in `dev/breeze/doc/09_release_management_tasks.rst` ("Syncing
the staging site with main") and the generated
`output_workflow-run_sync-staging-to-main.svg` need to be updated accordingly,
and the command parameters in `workflow_commands_config.py` should include the
new flag.
### Acceptance criteria
- Running the command while `staging` contains commits not on `main` fails
with a message listing those commits and naming the flag that acknowledges
dropping them.
- Running the command with the acknowledgement flag still asks for the
existing confirmation, then triggers the workflows.
- Running the command while `staging` is equal to or behind `main` behaves
exactly as today.
- Breeze unit tests cover the three cases above.
### Related
- The command and release step were added in #73653.
---
Drafted-by: Claude Code (Fable 5.1) (no human review before posting)
--
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]
