goutamadwant opened a new pull request, #12473: URL: https://github.com/apache/seatunnel/pull/12473
### Purpose of this pull request Related: #11513 (status reporting track). This does not overlap #11515. That PR's remaining `update_build_status.yml` change bumps `github-script` to v7 and adds `per_page: 100` to the check-runs call. This PR makes the same `per_page: 100` edit and leaves the `github-script` version alone, so the two merge without conflicts. `update_build_status.yml` mirrors each fork `Build` run onto the PR's `Build` check. The mirror logs from 80 consecutive runs (2026-09-22 05:42Z to 2026-09-23 05:50Z) and two fork runs show three problems. **1. A re-run keeps showing the previous attempt's result.** Fork run https://github.com/goutamadwant/seatunnel/actions/runs/35673416231 (PR #12360): - Attempt 1 failed at 01:53Z (Maven wrapper download got HTTP 429). - Attempt 2 ran from 05:59Z to 04:51Z the next day. During those 23 hours, the updater logged `Patch PR #12360 check run 106574782200: completed -> in_progress` 73 times without error. The check stayed `completed/failure` the whole time. GitHub accepts the PATCH but does not move a completed check run back to `in_progress`. The check turned `success` only when attempt 2 finished, and its `completed_at` still reads 01:55:20Z. In the same 24 hours, 14 PRs hit this (185 such patches). **2. Real failures are reported as `cancelled`.** A job that reaches `timeout-minutes` ends as `cancelled`, and GitHub then concludes the whole run as `cancelled`. Example: https://github.com/goutamadwant/seatunnel/actions/runs/35958838421. - 3 jobs failed: `transform-v2-it-part-1` (JDK 8) and `all-connectors-it-7` (JDK 8 and 11). - 4 jobs timed out. The annotation reads "The job has exceeded the maximum execution time of 1h30m0s". - The PR's `Build` check shows `cancelled`, which looks as if someone stopped the run. **3. Every Build check is re-patched on every tick.** `shouldSkipPatch` compares `details_url` with the fork run URL. GitHub keeps `details_url` of these check runs pointing at the check run itself (e.g. `https://github.com/apache/seatunnel/runs/106574782200`), so the two never match. Across the 80 runs, the updater sent 10,708 PATCH requests. The skip branch was never taken, and 10,434 of those requests (97%) changed nothing (`completed/failure -> completed/failure`, `in_progress -> in_progress`, …). Changes: - Build checks are listed with `per_page: 100` and ordered newest first before one is picked. - If the picked check is completed but the fork run is queued or in progress again, the updater creates a new `Build` check run for the same head SHA. It carries the same `{owner, repo, run_id}` pointer, and later ticks update it. This also covers a check left in `action_required`, which is a completed state too. - For a run that completed as `cancelled`, the updater lists its jobs. The result is `failure` if any job failed. Otherwise it is `timed_out` if a cancelled job has the timeout annotation (at most 10 annotation lookups, longest jobs first). Otherwise it stays `cancelled`. The same refinement applies when the queued-parent path derives `cancelled` from the job list. - If the Build check is already completed (not `action_required`) and its `completed_at` is at or after the run's `updated_at`, the PR is skipped: nothing is fetched or patched. Completing patches now set `completed_at`, so this holds from the next tick. - `shouldSkipPatch` compares only status and conclusion. - A workflow-level `concurrency` group (`update-build-status`, no cancel-in-progress) keeps two ticks from running at once. Risk controls: - A new check run is created only when the newest `Build` check is completed, the fork run is not, and no non-`action_required` `Build` check started at or after the current attempt's `run_started_at`. Together with the concurrency group, that means one new check per re-run attempt. After that, the newest check is the active one, so later ticks patch it. - The extra calls (job list, annotations) happen only for runs that concluded `cancelled`, and only until the Build check holds the final result. After that, the PR costs the same PR and check-run reads as today. Dropping the no-op PATCHes removes about 130 write calls per tick (10,434 over the 80 sampled ticks). - The queued-parent path keeps its logic and only gains the `cancelled` refinement above. No change to the search window or batching. `notify_test_workflow.yml` is untouched. ### Does this PR introduce _any_ user-facing change? No. CI status reporting only. ### How was this patch tested? - The embedded script was extracted from the workflow and run under Node 20 against a mocked `github.request`. The mock has 13 scenarios: re-run started, re-run still running with both checks listed, re-run finished green, cancelled with failed jobs, cancelled with timeouts only, cancelled by a user, already in sync, queued parent with active child jobs, run in progress with a queued check, a check left `action_required`, a repeat tick on an already-final check of a cancelled run (no job or annotation lookups, no write), a completed check already existing for the current attempt (no second create), and two consecutive ticks after a re-run starts (exactly one create). - Current `dev`: 4 of 13 behave as expected. The re-run cases patch the completed check, the cancelled-with-failures run stays `cancelled`, and in-sync or final checks are still patched every tick. - This branch: 13 of 13. - YAML parsing and `git diff --check`. Fork CI on this branch: https://github.com/goutamadwant/seatunnel/actions/runs/36140937054. It was queued when this PR was opened, and only the gate jobs run for this change. Not verified before merge: this workflow runs only on the schedule of `apache/seatunnel`, so a fork run cannot exercise it on real PRs. Two `Build` check runs on one head SHA already happen today when a PR is `reopened` (`notify_test_workflow.yml` creates a new one for the same SHA). That the newest one then counts as the required status is inferred from that precedent, not verified live. After merge, the updater logs should show: - `Create Build check run for PR #…` when a fork run is re-run; - `Skip PR #…: … is already final …` or `… already matches …` for unchanged PRs; - far fewer `Patch PR` lines per tick. Known limitation: the `Dead links` job is `continue-on-error`. If it failed in a run that was otherwise only cancelled, the check reports `failure` instead of `cancelled`, and if the other jobs only timed out, a real timeout is reported as `failure` instead of `timed_out`. ### Check list * [ ] If any new Jar binary package adding in your PR, please add License Notice according [New License Guide](https://github.com/apache/seatunnel/blob/dev/docs/en/developer/new-license.md) * [ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs * [ ] If necessary, please update `incompatible-changes.md` to describe the incompatibility caused by this PR. * [ ] If you are contributing the connector code, please check that the following files are updated: 1. Update [plugin-mapping.properties](https://github.com/apache/seatunnel/blob/dev/plugin-mapping.properties) and add new connector information in it 2. Update the pom file of [seatunnel-dist](https://github.com/apache/seatunnel/blob/dev/seatunnel-dist/pom.xml) 3. Add ci label in [label-scope-conf](https://github.com/apache/seatunnel/blob/dev/.github/workflows/labeler/label-scope-conf.yml) 4. Add e2e testcase in [seatunnel-e2e](https://github.com/apache/seatunnel/tree/dev/seatunnel-e2e/seatunnel-connector-v2-e2e/) 5. Update connector [plugin_config](https://github.com/apache/seatunnel/blob/dev/config/plugin_config) -- 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]
