Aias00 opened a new issue, #6683: URL: https://github.com/apache/shenyu/issues/6683
### [CI] `ci.yml` build matrix cancels sibling OS jobs on first failure and the `build` job has no `timeout-minutes` While diagnosing a `build` workflow failure (run [30756841941](https://github.com/apache/shenyu/actions/runs/30756841941) on PR #6456), I found two `ci.yml` config issues that make build failures harder to diagnose and waste runner time. Neither is the cause of any specific test failure — they're CI-hygiene improvements surfaced while tracing one. #### 1. `build` matrix uses the default `fail-fast: true` `.github/workflows/ci.yml`'s `build` job defines a `strategy.matrix` of 5 jobs (`windows-latest`/Java 17, `ubuntu-latest`/Java 17/19/20/21) but does not set `fail-fast`, so the GitHub default `fail-fast: true` applies: when one matrix job fails, the others are cancelled mid-build. In run 30756841941, `build (17, windows-latest)` failed with real test errors, and the four ubuntu jobs were each cancelled ~7 minutes into their builds (`status: cancelled`, log error `The operation was canceled.`). Concretely, this: - **Wastes partial build work.** Each cancelled ubuntu job had already compiled and tested many modules (~7 min) before being killed; that work is thrown away and re-run from scratch on the next push. - **Obscures whether a failure is OS-specific or universal.** Four of five jobs show "canceled" rather than a real result, so a reviewer has to open the per-job conclusions to find which job actually failed versus was merely cancelled. In this case the ubuntu jobs had not yet reached the failing module, so it was not obvious that the failure was platform-independent. Suggestion: set `fail-fast: false` on the `build` strategy so each OS job completes, making OS-specific vs universal failures immediately distinguishable and avoiding the cancelled-sibling confusion. ```yaml build: needs: changes strategy: fail-fast: false matrix: ... ``` #### 2. The `build` job has no `timeout-minutes` Only `check-license-header` sets `timeout-minutes` (10). The `build` job runs the full reactor (`mvnd -B clean test -Prelease -DskipRemoteResources=true` on Linux, `./mvnw.cmd -B clean test -Prelease` on Windows) and inherits GitHub's default 6-hour job timeout. A hung build (e.g., a test blocking on a socket) could consume a runner for up to 6 hours before being killed. Suggestion: set an explicit `timeout-minutes` on the `build` job (e.g., 60–90) so a hung build fails fast instead of holding a runner for hours. ```yaml - name: Build with Maven shell: bash timeout-minutes: 90 run: | ... ``` #### Side note on `concurrency.cancel-in-progress` The workflow already has `concurrency: { cancel-in-progress: true }` keyed by PR number, which is the right call for saving CI minutes on actively-iterated PRs. The `fail-fast`/`timeout-minutes` items above are independent of that and complementary. -- 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]
