build: bootstrap on 1.0.0-M11, and retire the v1 layout fallback - #638
Merged
Conversation
CI bootstraps this build with the previous release, pinned by `$version`. That was still 1.0.0-M9, two releases back and — more importantly — from before the `.bleep/` layout changed. So the bleep that compiled this tree wrote v1 paths while the tree itself expected v2, and the difference was papered over in two places. Bumping to M11 makes the bootstrapping bleep and the tree agree, which lets one of those papers come off. `BuildPaths` no longer appends `.bleep/generated-sources/<cross>/` to the source list. Its own comment named the exit condition — "once a v2-aware bleep is shipping everywhere and no v1 dirs survive bootstraps, this whole block can go" — and this is that. Removing it also drops the acknowledged ADT abuse it forced, where legacy sourcegen paths were smuggled through the `ksp` field to avoid changing `DirsByOrigin`. The fallback is not merely unnecessary now, it is harmful: a worktree that still has a stale v1 directory gets the same generated file from both layouts, and the compile fails with "BleepVersion is already defined". Anyone upgrading an existing worktree should `rm -rf .bleep` once — M11 already invalidates every analysis and class directory in there, so nothing in it is worth keeping. Fresh checkouts are unaffected. `scripts-init` needed one real fix. It declared only bleep-plugin-dynver and got bleep-core transitively, which stopped being true in M11: #591 merged the sbt-pgp/sonatype/ci-release sources INTO bleep-core to break a cycle, flipping that edge, so the M11 dynver POM lists no bleep-core at all. Verified against both published POMs. The failure was awkward — the project compiled clean and then the sourcegen fork died with NoClassDefFoundError on BleepCodegenScript$Target, because its compile classpath and the forked runtime classpath are assembled from different things. It cannot `dependsOn: bleep-core` like other script projects, since it sourcegens BleepVersion.scala for bleep-model, so it declares a published bleep-core instead. Verified with `bleep.release` rather than a snapshot binary: a snapshot ignores `$version` outright ("Not launching Bleep version ... because you're running a snapshot"), so it cannot exercise this at all. Full build: 25 projects compiled, 0 failed. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
oyvindberg
force-pushed
the
bump-bootstrap-m11
branch
from
August 2, 2026 12:55
4dc23db to
6b14df0
Compare
The bump broke every native-image job, in the way this release's own notes warn about: silently, at a coordinate nobody asks for. Four steps each carried their own copy of a grep against `.bleep/generated-sources/bleep-model/...` — the pre-M11 layout. Bootstrapping on M11 means sourcegen writes `.bleep/projects/bleep-model/generated-sources/...` instead, so all four matched nothing at once and produced an empty version. `publish-local --version ""` then published under something other than what the client had compiled into it, and the failure surfaced two steps later as Error resolving dependencies for installing bleep-bsp:1.0.0-M11+4-84137fd8-SNAPSHOT not found: /home/runner/.ivy2/local/build.bleep/bleep-bsp_3/... which names the version the binary wanted and says nothing about the publish that used a different one. Extracted to `.github/scripts/bleep-version.sh`, so the path exists once rather than four times — four copies is why one layout change broke four steps. It fails loudly on a missing file or an unparseable version, because an empty version is the dangerous outcome here: it publishes successfully, and only a later resolution reveals the mismatch. Verified against a real generated file (prints 1.0.0-M11+1-cb15f2ea-SNAPSHOT) and against a directory without one (exits 1 with a workflow error annotation). Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CI bootstraps this build with the previous release, pinned by
$version— still1.0.0-M9, two releases back and, more to the point, from before the.bleep/layout changed. The bleep compiling this tree wrote v1 paths while the tree expected v2, and that gap was papered over in two places.What this does
$version: 1.0.0-M9→1.0.0-M11. Verified all M11 artifacts are on Maven Central first (bleep-plugin-native-image,-scalafix,-dynver,bleep-bsp,bleep-core,bleepscript, andbleep-test-runner— the last publishes without a Scala suffix, being Java, same as M10).Retires the v1 generated-sources fallback in
BuildPaths. Its own comment named the exit condition: "Once a v2-aware bleep is shipping everywhere and no v1 dirs survive bootstraps, this whole block can go." This is that. It also drops the ADT abuse the fallback forced, where legacy sourcegen paths were threaded through thekspfield to avoid changingDirsByOrigin.That fallback is no longer merely redundant — it is now harmful. A worktree holding a stale v1 directory gets the same generated file from both layouts and the compile dies with
BleepVersion is already defined. Hit this locally; that is what surfaced it.Fixes
scripts-init. It declared onlybleep-plugin-dynverand receivedbleep-coretransitively. That stopped being true in M11 — #591 merged the sbt-pgp/sonatype/ci-release sources into bleep-core to break a cycle, flipping the edge. Confirmed against the published POMs:bleep-plugin-dynver_3dependenciesbleep-core_3:1.0.0-M9✅The failure mode was awkward: the project compiled clean, then the sourcegen fork died with
NoClassDefFoundError: bleep/BleepCodegenScript$Target, because the compile classpath and the forked runtime classpath are assembled from different things. It can'tdependsOn: bleep-corethe way other script projects do — it sourcegensBleepVersion.scalaforbleep-model, so an in-tree edge is circular — hence a publishedbleep-coreat${BLEEP_VERSION}.Remove the stale v1 trees once:
The whole directory, not just the generated-source trees: M11 also changed the Zinc analysis format, so every analysis and class directory in there is already invalid. Nothing in
.bleepis worth keeping and it is rebuilt on the next command. Fresh checkouts are unaffected.Verification
Tested with
bleep.release, not a snapshot — a snapshot binary ignores$versionoutright (Not launching Bleep version 1.0.0-M11 ... because you're running a snapshot), so it cannot exercise this path at all. That's also why local testing only goes so far here and CI is the real check.bleep.release compile→ 25 projects compiled, 0 failedbleep fmtclean🤖 Generated with Claude Code