You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Maven CI matrix has no Windows leg, a stale 4.0 RC, and no legs at the resolver boundaries #267
[agent] Filed by Claude Code on behalf of Mikola Lysenko (@mikolalysenko) while adding Maven patch SBOM annotations to depscan. Repro artifacts were produced with real Maven and a stub patch API.
Summary
The real-Maven capstones (e2e_redirect_maven_build, e2e_vendor_maven_build) run on:
ubuntu with 3.6.3, 3.8.9, 3.9.16 and 4.0.0-rc-6
macOS with 3.9.16
This leaves the following gaps:
No Windows leg. The vendored <url>file://${project.basedir}/.socket/vendor/maven/<uuid></url> interpolates to file://C:\…\.socket/vendor/… on Windows. Nothing verifies that Maven resolves that form, with its mixed separators and missing third slash. The install step also exports bin/mvn (the POSIX script) and extracts only the .tar.gz. A Windows leg needs the .zip and bin\mvn.cmd, and mvn_command needs to run it through cmd /c.
4.0.0-rc-6 is stale. 4.0.0-rc-7 is current on dlcdn/archive. Verified locally: rc-7 passes both the hosted and vendored flows, and it enforces Trusted Checksums with the resolver-2 message.
No boundary legs:
3.9.3 / 3.9.4: the Trusted Checksums enforcement boundary (see the separate issue).
3.10.0-rc-1: Resolver 2 on the 3.x line, with a different checksum-failure message and .meta/prefixes.txt probing.
Nothing below 3.6.3. That may be intentional, but it should be documented as the floor.
Impact
The Windows vendored path is completely untested, and a silent fail-open there (the file:// URL not resolving, so Maven falls through to Central at the same GAV) would not be caught.
Resolver-2-specific behavior (prefix-file probes against the Socket repo, message format) is untested on the 3.x line.
Repro / evidence
.github/workflows/ci.yml:981-993 (matrix) and :1165-1186 (install step: .tar.gz only, exports …/bin/mvn).
Local darwin/arm64 runs against the CLI built from 3efdc31d:
[agent] Re-verified against origin/main (578b63e) on 2026-10-11. Still partly applies:
Done: the 3.9.3 / 3.9.4 trusted-checksums boundary legs exist (.github/workflows/ci.yml:1833-1834, full tier), plus maven_reactor legs on 3.6.3 / 3.8.9 / 3.9.2 / 3.9.16 / 4.0.0-rc-6 (ci.yml:1835-1839).
Still open: 4.0.0-rc-6 is still the 4.x pin (ci.yml:1832, :1839). The only Windows Maven leg is e2e_vendor_jvm_buildmaven_reactor (ci.yml:1896); there is no Windows e2e_redirect_maven_build / e2e_vendor_maven_build leg. There is no 3.10.0-rc-1 leg.
The PR tier runs one Maven leg (3.9.16, ci.yml:1242). Under the lean-CI rules any new leg belongs in the full tier only (schedule / dispatch), not on PRs or the merge queue.
[agent] Claiming this issue (slice: move the 4.x Maven pin from 4.0.0-rc-6 to 4.0.0-rc-7 in the full tier). Branch: agent/fix-ci-maven-4-rc7-pin. Claim-ID: 2026-10-12T18:50:36Z-554677
[agent] #1443 (ready, CI green) moves the full-tier Maven 4 legs from 4.0.0-rc-6 to 4.0.0-rc-7. It uses Refs, not Fixes, so this issue stays open for the rest:
no Windows e2e_redirect_maven_build / e2e_vendor_maven_build leg;
no Maven 3.10 leg (3.10.0 GA is now on Central).
Each one adds a full-tier job, so under the post-2026-10-10 runner budget a maintainer should decide whether they're worth the nightly cost. Leaving agent:claimed on until CI: test Maven 4 on 4.0.0-rc-7 (#267) #1443 merges.
[agent] #1443 has merged: the full-tier Maven 4 legs now run 4.0.0-rc-7. I'm removing agent:claimed. What's left here (a Windows e2e_redirect_maven_build / e2e_vendor_maven_build leg and a Maven 3.10 leg) adds full-tier jobs and needs a maintainer to decide whether it's worth the nightly cost.
Activity
mikolalysenko commentedon Oct 11, 2026
[agent] Re-verified against origin/main (578b63e) on 2026-10-11. Still partly applies:
.github/workflows/ci.yml:1833-1834, full tier), plusmaven_reactorlegs on 3.6.3 / 3.8.9 / 3.9.2 / 3.9.16 / 4.0.0-rc-6 (ci.yml:1835-1839).ci.yml:1832,:1839). The only Windows Maven leg ise2e_vendor_jvm_buildmaven_reactor(ci.yml:1896); there is no Windowse2e_redirect_maven_build/e2e_vendor_maven_buildleg. There is no 3.10.0-rc-1 leg.ci.yml:1242). Under the lean-CI rules any new leg belongs in the full tier only (schedule / dispatch), not on PRs or the merge queue.Generated by Claude Code
mikolalysenko commentedon Oct 12, 2026
[agent] Claiming this issue (slice: move the 4.x Maven pin from 4.0.0-rc-6 to 4.0.0-rc-7 in the full tier). Branch: agent/fix-ci-maven-4-rc7-pin. Claim-ID: 2026-10-12T18:50:36Z-554677
Generated by Claude Code
mikolalysenko commentedon Oct 12, 2026
[agent] Draft PR: #1443
Generated by Claude Code
Docs: name the tiers that run each Maven pin
mikolalysenko commentedon Oct 12, 2026
[agent] #1443 (ready, CI green) moves the full-tier Maven 4 legs from 4.0.0-rc-6 to 4.0.0-rc-7. It uses
Refs, notFixes, so this issue stays open for the rest:e2e_redirect_maven_build/e2e_vendor_maven_buildleg;Each one adds a full-tier job, so under the post-2026-10-10 runner budget a maintainer should decide whether they're worth the nightly cost. Leaving
agent:claimedon until CI: test Maven 4 on 4.0.0-rc-7 (#267) #1443 merges.Generated by Claude Code
mikolalysenko commentedon Oct 12, 2026
[agent] #1443 has merged: the full-tier Maven 4 legs now run 4.0.0-rc-7. I'm removing
agent:claimed. What's left here (a Windowse2e_redirect_maven_build/e2e_vendor_maven_buildleg and a Maven 3.10 leg) adds full-tier jobs and needs a maintainer to decide whether it's worth the nightly cost.Generated by Claude Code