mirror of
https://github.com/gradle/actions.git
synced 2026-09-10 19:28:33 +08:00
e49d0a36a8
This PR reports the support status of every Gradle version used in a workflow: - **End-of-life** — two or more major versions behind the latest release. - **Out of date** — one major version behind the latest release, or more than two minor versions behind on the current major. The information is surfaced as job annotations and in the Job Summary: an icon beside the Gradle version in the build results table, and a message below it. | version kind | job annotation | version table | below the table | | ------ | ----- | ---- | --------- | | EOL | warning | ⚠️ | expandable section, pointing to the Gradle Security Subscription | | Out of date | notice | ℹ️ | one-line legend, pointing to the Gradle release lifecycle docs | | Current | none | — | — | A single expandable section covers every end-of-life version, naming them in its summary line and listing the affected release lines in its body. The upgrade legend likewise appears once per job, however many versions carry the info icon. Notes on what is deliberately *not* reported: - **Patch releases.** Only the major and minor version are considered, so being on `9.7.0` when `9.7.1` exists is not flagged. - **Pre-releases.** Release candidates, milestones and snapshots are never reported, so testing against a nightly or an RC produces no annotations. The latest Gradle release is determined from the wrapper checksum data already bundled with the action, so no network access is required. That data is refreshed weekly, and the two-minor grace band absorbs the lag. Note that the annotations are emitted independently of `add-job-summary`: setting it to `never` suppresses the Job Summary itself, but the warning and notice annotations remain. ### Examples The `demo-job-summary` workflow has a `support-status-eol-and-outdated` job that builds with three end-of-life versions (`6.9.4`, `7.4`, `7.6.6`), two out-of-date versions (`8.0.2`, `8.14.5`) and the current release, so all three statuses appear in one summary: * **Job Summary**: https://github.com/gradle/actions/actions/runs/34166688755#summary-101879071306 * **Annotations**: https://github.com/gradle/actions/actions/runs/34166688755/job/101879071306 (expand annotations) That workflow is never triggered automatically; run it manually against a branch to review the rendering. ### Implementation * Adds `GradleVersion`, parsing and ordering versions the same way Gradle's own `org.gradle.util.GradleVersion` does. This replaces the previous `versionIsAtLeast` helper and removes the `semver` dependency. * Adds `gradle-support-status.ts`, which owns the classification policy and both of its presentations (annotations and Job Summary section) behind a three-function API, so `job-summary.ts` only asks for the icon and the rendered block. ### Testing * Unit tests for version ordering, classification, the annotations and the rendered summary. * `integ-test-gradle-support-status.yml`, which derives its expected versions from the bundled release data so the assertions cannot drift from the action's own view, then asserts against the real job log. * The demo workflow job linked above, for reviewing the rendering by eye. Documented under [Build reporting](https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#gradle-version-support-status) in `docs/setup-gradle.md`. --------- Co-authored-by: Louis Jacomet <louis@gradle.com> Co-authored-by: Daz DeBoer <daz@gradle.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
5 lines
27 B
Plaintext
5 lines
27 B
Plaintext
.git
|
|
.vscode
|
|
.claude
|
|
.idea
|