Repository navigation
fix(deps, ci): bump sbt/setup-sbt to v1.5.14 to restore CI - #9346
Conversation
Automated Reviewer SuggestionsBased on the
|
|
Please hold off on merging this until apache/infrastructure-actions#1498 lands. v1.5.14 is not on the ASF allow list yet I added |
|
Apache Pekko is broken by the same failure: jobs that miss the sbt download cache die in This also isn't the first time setup-sbt's signature verification step has broken builds. sbt/setup-sbt#118 ( v1.5.14 fixes the immediate problem, but we've started a discussion in Pekko about replacing Input from Texera would be welcome, as you'd be affected by the same issues. If there's interest, a shared approach might make more sense than each project doing its own. |
Thanks for the context, and for helping get apache/infrastructure-actions#1498 through! We'll take v1.5.14 here to get CI working again, and we're happy to join the discussion. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9346 +/- ##
============================================
+ Coverage 91.86% 92.87% +1.01%
- Complexity 5022 6278 +1256
============================================
Files 1277 1313 +36
Lines 56170 70896 +14726
Branches 7314 10142 +2828
============================================
+ Hits 51598 65846 +14248
- Misses 2740 3026 +286
- Partials 1832 2024 +192
☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
| config | throughput | MB/s | latency | max Δ latest / 7d | |
|---|---|---|---|---|---|
| 🔴 | bs=10 sw=10 sl=64 | 383 | 0.234 | 24,194/36,714/36,714 us | 🔴 +12.4% / 🔴 +184.9% |
| 🟢 | bs=100 sw=10 sl=64 | 828 | 0.505 | 119,031/164,903/164,903 us | 🟢 -13.2% / 🔴 +85.4% |
| 🔴 | bs=1000 sw=10 sl=64 | 970 | 0.592 | 1,026,151/1,146,778/1,146,778 us | 🔴 +6.1% / 🔴 +32.6% |
Baseline details
Latest main bb6136d from same runner
| config | metric | PR | latest main | 7d avg | Δ latest | Δ 7d |
|---|---|---|---|---|---|---|
| bs=10 sw=10 sl=64 | throughput | 383 tuples/sec | 423 tuples/sec | 953.99 tuples/sec | -9.5% | -59.9% |
| bs=10 sw=10 sl=64 | MB/s | 0.234 MB/s | 0.258 MB/s | 0.582 MB/s | -9.3% | -59.8% |
| bs=10 sw=10 sl=64 | p50 | 24,194 us | 21,533 us | 10,584 us | +12.4% | +128.6% |
| bs=10 sw=10 sl=64 | p95 | 36,714 us | 36,837 us | 12,888 us | -0.3% | +184.9% |
| bs=10 sw=10 sl=64 | p99 | 36,714 us | 36,837 us | 16,266 us | -0.3% | +125.7% |
| bs=100 sw=10 sl=64 | throughput | 828 tuples/sec | 782 tuples/sec | 1,242 tuples/sec | +5.9% | -33.4% |
| bs=100 sw=10 sl=64 | MB/s | 0.505 MB/s | 0.478 MB/s | 0.758 MB/s | +5.6% | -33.4% |
| bs=100 sw=10 sl=64 | p50 | 119,031 us | 115,322 us | 83,370 us | +3.2% | +42.8% |
| bs=100 sw=10 sl=64 | p95 | 164,903 us | 189,959 us | 88,966 us | -13.2% | +85.4% |
| bs=100 sw=10 sl=64 | p99 | 164,903 us | 189,959 us | 101,186 us | -13.2% | +63.0% |
| bs=1000 sw=10 sl=64 | throughput | 970 tuples/sec | 975 tuples/sec | 1,276 tuples/sec | -0.5% | -24.0% |
| bs=1000 sw=10 sl=64 | MB/s | 0.592 MB/s | 0.595 MB/s | 0.779 MB/s | -0.5% | -24.0% |
| bs=1000 sw=10 sl=64 | p50 | 1,026,151 us | 1,025,241 us | 815,662 us | +0.1% | +25.8% |
| bs=1000 sw=10 sl=64 | p95 | 1,146,778 us | 1,081,043 us | 864,800 us | +6.1% | +32.6% |
| bs=1000 sw=10 sl=64 | p99 | 1,146,778 us | 1,081,043 us | 896,884 us | +6.1% | +27.9% |
Raw CSV
config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,521.93,200,128000,383,0.234,24194.06,36714.24,36714.24
1,100,10,64,20,2415.08,2000,1280000,828,0.505,119031.00,164902.99,164902.99
2,1000,10,64,20,20610.35,20000,12800000,970,0.592,1026150.89,1146777.71,1146777.71
|
Thanks, PJ. I think having a shared approach might work. Indeed having the action break even though nothing changed on our side is extremely annoying, but also concerning from a security standpoint. Is the idea to basically have an action that better fits the usage of sbt between Pekko and Texera? Something similar to the action you proposed in the Pekko PR, that gets sbt with curl? And, if it was an action in a separate repo, then it could cache like the current action or the coursier action, but be simpler overall? |
What changes were proposed in this PR?
Nothing can merge into main right now. Every job that sets up sbt (
amber,amber-integration,platform×6,platform-integration×6,Bench, the image builds and the dependency graph) has died atSetup sbt launchersince 2026-11-05 15:36 UTC, on main itself and on every PR, soRequired Checksis red and the merge queue takes nothing. Nothing in this repository changed: main at312a0cefc(#9325, run at 07:16 UTC) was green, main at8b0fb168e(#8848, run at 20:54 UTC) is red, and that commit touches three frontend files.Before: Scala job -> sbt/setup-sbt v1.5.12 -> "Verify the sbt distribution signature" reads carabiner-dev/policies at HEAD -> ampel v1.3.6 cannot parse it -> exit 1 before sbt is installed
After: Scala job -> sbt/setup-sbt v1.5.14 -> the same step reads the policy pinned at carabiner-dev/policies@971d670e9 -> sbt installs -> the job runs
Root cause. v1.5.12 hands
carabiner-dev/actions/ampel/verify@32587e8(ampel v1.3.6) the policy argumentgit+https://github.com/carabiner-dev/policies#signature/signature.json, with no ref, so the policy is whatever that repository's main holds at run time. On 2026-11-05signature/signature.jsongained ameta.namefield that ampel v1.3.6 rejects, and ampel exits while loading the policy withcompiling policy: unable to parse a policy, group or policySet from data. The step'sfail: falsecovers a failed verification verdict, not the loader exiting, so the composite action fails and the job stops. sbt/setup-sbt#155, released as v1.5.14 the same day, pins the policy tocarabiner-dev/policies@971d670e93f2fb4da304b0e5f071066dc4686a5a, a commit without the field.Change. All 9 call sites (
build.yml×4,build-and-push-images.yml×3,benchmarks.yml,dependency-graph.yml) move fromecad189dd245444b9ae0a0cd5922fd938b88906f(v1.5.12) to67d461eba2c4753196c230e02da850757ba4775e(v1.5.14), as #9100 moved them to v1.5.12. Between the two versionsaction.ymldiffers in two lines: the policy pin above and the defaultsbt-runner-version(2.0.10 -> 2.0.12), which this repository does not use becauseproject/build.propertiessetssbt.version. The nested actions,actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9andcarabiner-dev/actions/ampel/verify@32587e82f960d49b36101e8c45d1956e511965d3, are the same in both, and no call site passes inputs.Scope. v1.5.13 is already on the ASF allow list but carries the same unpinned policy line, so it fails the same way; v1.5.14 is the first version that does not. This PR changes nothing about what the signature step does when it runs; it only stops the step from reading a moving target.
Blocked on apache/infrastructure-actions#1498.
sbt/setup-sbt@67d461ebais not on the ASF actions allow list yet; #1498 (opened 2026-11-05 13:39 UTC) adds it. Until it merges, every sbt job on this PR fails atSet up jobwith the action not allowed, which is how v1.5.7 failed in #9100, so the red checks here are expected and this PR must not be merged before #1498 lands. Once it does, a re-run of the failed jobs is the proof; nothing in this branch needs to change.Any related issues, documentation, discussions?
Closes #9345.
Upstream fix: sbt/setup-sbt#155 (v1.5.14). Allow-list entry: apache/infrastructure-actions#1498. Precedent: #9100 moved the same 9 call sites to v1.5.12 after the ASF allow list dropped the actions v1.5.7 reached, with backports #9132 (v1.3) and #9133 (v1.2); #7710 and #6990 are the earlier bumps of the same kind.
How was this PR tested?
Every changed file parses:
git ls-remote --tags https://github.com/sbt/setup-sbt.gitresolvesrefs/tags/v1.5.14^{}to67d461eba2c4753196c230e02da850757ba4775e. Diffingaction.ymlatecad189against67d461ebashows only the two lines described above, with identicaluses:lines. Walking theuses:chain under v1.5.14 reachesampel/verify@32587e8, which is inapache/infrastructure-actionsapproved_patterns.yml;sbt/setup-sbt@67d461ebaitself is not yet, which apache/infrastructure-actions#1498 adds.The rest is CI. The labeler applies
cifor.github/**, which runs every stack that sets up sbt. Those jobs cannot pass until apache/infrastructure-actions#1498 lands (see above); the re-run after that is the test, and the checks on this PR are the first run of v1.5.14 in this repository.Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (claude-fable-5-1). Co-authored with Claude; the author reviewed the change before submission.