sjyangkevin commented on PR #76957: URL: https://github.com/apache/airflow/pull/76957#issuecomment-6842610081
### Update after review: branch tips from `apache/airflow`, and a question about `CI passed` Changes since last comment: - `ea2ec7f4d2` reads the release and constraints branches from `apache/airflow` instead of the repository the run is in, and checks out the branch tip from there. This answers the question in my previous comment: a run in a fork now tests the real branch tip. - The lookup now fails when it cannot find the branch of the latest release in the matrix, instead of passing with nothing to test. It also runs with `pipefail` now: before, a failed API call inside the pipe still gave an empty list and the job passed. - `126055982e` is an empty commit. It only starts the fork run again after I re-enabled Actions in my fork. - Rebased on `main`. #### Fork run with the change I deleted my fork's copies of `v3-4-test` and `constraints-3-4` first, so the job could only find the branch tip in `apache/airflow`. - **Run:** https://github.com/sjyangkevin/airflow/actions/runs/43344970930 | Step | Evidence in the log | |---|---| | The branch tip is read from `apache/airflow` | `v3-4-test: 6a6baff34dda9eea30c373d7412a2f871a6467fb` ([Find release branch tips](https://github.com/sjyangkevin/airflow/actions/runs/43344970930/job/131625892689)) | | It is checked out from `apache/airflow` | `Syncing repository: apache/airflow`, `HEAD is now at 6a6baff` ([Build Airflow from v3-4-test](https://github.com/sjyangkevin/airflow/actions/runs/43344970930/job/131627293198)) | | The wheels are built from that commit | `git_version of the airflow-core wheel: .release:6a6baff34d…` | | The tests install that build | `Installed apache-airflow-core 3.4.0 git_version: .release:6a6baff34d…` ([Compat v3-4-test](https://github.com/sjyangkevin/airflow/actions/runs/43344970930/job/131630461129)) | | Provider tests | 33,683 passed, 608 skipped, the same counts as Compat 3.4.0 in the same run | #### Question: should a failure on the branch tip block merges? The new job is in the `needs` of `CI passed` and `Check for timed-out CI jobs`. `CI passed` is the check `main` requires before a merge. The job runs on canary runs, on PRs with the `full tests needed` label, and on PRs that change its workflow. So if a backport breaks a provider test on `v3-4-test`, every PR with the `full tests needed` label fails `CI passed` until the branch is fixed, even when the PR has nothing to do with it. Running it again does not help, because the job picks up the same broken branch tip. The alternative is to remove the job from `CI passed` and `Check for timed-out CI jobs`, and add it to the `needs` of `Notify Slack`. `Notify Slack` waits for the rest of the run only through `CI passed`, so it needs the job listed directly. It reports every failed job of the run, timeouts included, so a broken branch tip would still show up in Slack after a canary run. The cost: a PR that changes `test-providers-branch-tip.yml` would no longer be blocked by its own failing job. Reviewers would still see it fail. -- 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]
