slachiewicz opened a new issue, #308: URL: https://github.com/apache/maven-gh-actions-shared/issues/308
`maven-verify.yml` defaults both `timeout-minutes` and `ff-timeout-minutes` to **360**, which is also the longest a GitHub-hosted job may run. The platform limit always fires first, so the input has never bounded a job. `setup-maven-version` has no `timeout-minutes` at all. apache/maven-executor#36 hit this on 10 Aug: a Markdown edit to the download page held `ubuntu-latest jdk-17-zulu` from 00:04:50 to 06:05:04 — exactly 360 minutes — then the run was cancelled and the rest of the matrix skipped. That repository's median job is 3.1 minutes. ## Measurements Last four successful `push` runs on the default branch of every repository in the `maven-sources` manifest: **3,776 matrix jobs, 76 repositories, 15,222 runner-minutes**. Duration is `completed_at − started_at` per job, so queue time is excluded — which is what `timeout-minutes` measures. 11 jobs (0.29%) were dropped as outliers before computing the figures below, using a Tukey fence of Q3 + 3×IQR within each repository/OS cell. Statistics are on the remaining 3,765. | | minutes | |---|---| | p50 | 2.5 | | p90 | 8.8 | | p95 | 11.3 | | p99 | 25.7 | | max | 38.0 | ### Where a cap would bite | Cap | Jobs killed | Share | Repositories | |---|---|---|---| | 10 min | 271 | 7.20% | 17 | | 15 min | 88 | 2.34% | 6 | | 20 min | 63 | 1.67% | 4 | | 25 min | 39 | 1.04% | 3 | | **30 min** | **15** | **0.40%** | **3** | | 45 min | 0 | 0% | 0 | | 360 min (today) | 0 | 0% | 0 | Only three repositories run past 30 minutes at all: | Repository | p50 | p99 | max | |---|---|---|---| | maven-surefire | 26.4 | 32.4 | 32.6 | | maven-scm | 7.2 | 32.7 | 32.9 | | maven-assembly-plugin | 12.3 | 29.5 | 38.0 | maven-invoker-plugin is the next one down at max 20.6. ## Proposal `timeout-minutes` 360 → **30**, `ff-timeout-minutes` 360 → **15**, and `timeout-minutes: 5` on `setup-maven-version` (its observed p90 is 5 seconds). Both inputs are already per-project overridable; the three repositories above would set 60. `timeout-minutes` counts from when a job starts executing, not from when it is queued, so this bounds runaway builds and not runner starvation. The existing `concurrency` group with `cancel-in-progress: true` already covers superseded pushes. ## Things worth discussing separately **The outliers may be real bugs.** Eleven jobs sat far outside their own repository/OS cell. Two look worth a look rather than a shrug: | Repository | Job | Duration | Cell fence | |---|---|---|---| | maven-assembly-plugin | ubuntu jdk21 | 61.5 min | 26.3 | | maven-archiver | ubuntu jdk25 | 21.6 min | 2.7 | | maven-build-cache-extension | windows jdk25 | 16.3 min | 16.0 | | maven-enforcer | ubuntu jdk25 | 11.2 min | 10.4 | | maven-project-info-reports-plugin | ubuntu jdk17 | 9.8 min | 6.3 | maven-archiver's is the striking one — eight times the fence for that cell, in a repository whose jobs otherwise finish in about two minutes. **maven-jdeps-plugin runs 55 jobs per push.** It sets `jdk-distribution-matrix` to four vendors, which multiplies the whole OS × JDK grid. Wall clock is 2.8 minutes but it costs 94 runner-minutes — as much as maven-scm. Does vendor coverage need to run on every push, or would a nightly schedule give the same signal? **Windows costs 1.51× Linux for identical work.** Measured as a paired per-repository median across 72 repositories, so it is not a mix effect. Windows is 30.8% of jobs and 41.4% of runner-minutes. Worth knowing how much of that is toolchain setup and dependency resolution rather than the build itself. **JDK version does not affect duration.** p50 is 2.1–2.6 minutes for 8, 17, 21 and 25 alike. JDK 11 appears to be an outlier at p50 27.8 only because maven-surefire is the only repository still running it. **Heaviest repositories per run**, in runner-minutes: maven-surefire 310, maven-assembly-plugin 211, maven-compiler-plugin 179, maven-invoker-plugin 172. <sub>Drafted with Claude — please verify</sub> -- 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]
