[ci] Auto-rerun flaky integration-test jobs on a fresh runner

[weiqingy]

Linked issue: #893

Purpose of change

The integration-test jobs (it-python, it-java, cross-language) depend on a live local Ollama server and, on flink-1.20, a PyFlink py4j gateway. Both fail intermittently for environmental reasons: the llama-server runner segfaults (~20% per job) and the py4j gateway occasionally dies. Both survive the in-suite reruns already configured (pytest --reruns 2, surefire rerunFailingTestsCount=2), because within one job those retry into the same wedged process.

These failures are per-runner and version-neutral — the same job passes on ~80% of fresh runners, and across a run the failures roam between matrix jobs rather than pinning to one. The flake also has a dated onset with no matching Ollama release (the installed version has been constant across both the green and the red days), so it tracks the runner environment rather than a version regression. The reliable way to clear them is therefore a fresh runner, not a larger in-suite retry count, an in-process restart, or an Ollama version pin.

This adds a workflow_run companion that, when the CI run finishes in failure, re-runs only the failed integration-test jobs on a fresh runner, which resets the whole job environment. Unit-test, lint, and build failures are never re-run, so a real regression there stays red immediately. The retry is bounded by run_attempt (at most two re-runs) so a genuinely broken job — which fails on every fresh runner — still goes red instead of looping.

Tests

The mechanism was validated end-to-end on a fork: a failed job matching the integration-test filter is re-run on a fresh runner and the run flips green, a non-matching job is left untouched, and the run_attempt cap stops the retry chain. The job-name filter was checked against the current CI job names, so only it-python / it-java / cross-language match; the unit-test jobs (ut-python / ut-java), Code Style Check, install.sh tests, and ut-build-backend are excluded.

Two operational notes for reviewers: the companion needs actions: write on the workflow token to re-run jobs (the existing labeler companions already run on write-scoped tokens), and because workflow_run companions execute from the default branch, this takes effect after merge and cannot be exercised on this PR's own CI.

API

No public API changes; this only affects CI.

Documentation

• doc-needed
• doc-not-needed
• doc-included

[weiqingy]

Note on this PR's own CI, to avoid a misread: the two red legs (it-java [flink-1.20] and it-java [java-21] [flink-2.0]) are the llama-server segfault flake this PR targets — llama-server process has terminated: signal: segmentation fault (core dumped). This change only adds a workflow file and touches no test or build path, so it cannot itself cause a test failure.

This PR cannot demonstrate the fix on its own CI: a workflow_run companion runs only from the copy of the file on the default branch, so it is not active for this PR's run. Once merged it activates for every subsequent "Flink Agents CI" run, including pull-request runs — a failed integration-test leg is re-run on a fresh runner and its check flips to green, while a genuine failure that reproduces on every fresh runner stays red. That is the intended signal: a flaky failure auto-heals, a real one persists.

I validated the mechanism end-to-end on a fork (companion on the fork's default branch): a failed integration-test-named job was re-run on a fresh runner and the run flipped green, a non-matching job was left untouched, and the run_attempt cap stopped the retry chain. This mirrors the existing pr_labeler / issue_labeler companions, which likewise run from the default branch via workflow_run.