Repository navigation
Tags
Tags
fix(ci): build Scala.js modules on the same Scala 3 version as JVM (#… …1705) * build: build Scala.js modules on the same Scala 3 version as JVM jsSettings stripped the latest Scala 3 from every JS cross build, a workaround for a Scala.js 3.7.4 'virtualfile:' URI compiler bug. That left JS modules on 3.3.7 while JVM modules used 3.9.0, and a release that switches versions mid-session mixed TASTy from both compilers. Drop the filter and the per-module crossScalaVersions re-adds. * build: drop stale jsSettings comment in async-benchmarks-js jsSettings no longer pins JS to 3.3.7, and the scalaVersion and crossScalaVersions overrides repeat what stdSettings already sets.
fix(ci): unconditionally disable Test/packageDoc, not just on snapsho… …ts (#1698) The previous commit (84881b4) only skipped Test/packageDoc for snapshot builds, mirroring Compile/packageDoc. But the CI failure that motivated this was on a tagged release (v0.0.52), where isSnapshot is false, so that fix does nothing for real releases. Test/packageBin and Test/packageSrc are never published (sbt leaves them off by default), so the Test/packageDoc jar had no corresponding binary to document in the first place — a dangling artifact sbt builds by default for any config with a `doc` task. Disabling it unconditionally is what actually stops `Test / doc` from running during release/publish at all, which is what crashed scaladoc for streamsJS/streamsJVM on the v0.0.52 release (Compile/doc for streams succeeds fine; only Test/doc crashes).
fix(build): align websiteDir with mdocOut in docs project (#1556) publishToNpmTask (zio-sbt-website's WebsitePlugin) locates the docs directory via websiteDir.value/docs, which defaults to <target>/website/docs. This project overrides mdocOut to instead write compiled docs to the repo-root website/docs, but never updated websiteDir to match, so publishToNpmTask always looked for docs in a directory nothing ever created. Java's ProcessBuilder throws the same generic "Cannot run program npm ... No such file or directory" message for both a missing executable and a missing working directory, which is why this surfaced as what looked like a PATH problem on every Release Docs run. Override websiteDir to point at the same root website/ directory, so websiteDir/docs resolves to where mdoc actually writes. Verified locally on this branch: removed website/docs, regenerated it via `sbt docs/mdoc`, then ran the exact command sequence publishToNpmTask executes in that directory (npm version, npm pkg set repository.url, npm config set access public, npm publish --dry-run) - all succeeded, confirming the directory mismatch is resolved. Supersedes #1512, which diagnosed and fixed the same issue but was never merged and is now stale against main. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
fix(ci): cache dependencies in release job (#1555) The release job has no coursier/cache-action step, unlike every other job in this workflow. sbt ci-release compiles and generates Scaladoc across every module cross-built for 2.13/3.3/3.8 on JVM and JS; from a cold cache this can run long enough to collide with the job's 60-minute timeout mid-publish. Testing cache alone first, isolated from other release-job changes, to see whether it's sufficient before touching anything else. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
fix(ci): drop npm cache from Release Docs setup-node (#1553) actions/setup-node with cache: 'npm' hard-fails when no lockfile matches at repo root ("Dependencies lock file is not found"). The repo has no root package.json/package-lock.json — the only lockfile is website/yarn.lock, and the docs publish step runs sbt docs/publishToNpm, which generates the npm package rather than running npm install. The cache is therefore both broken and useless. Removing it lets the Release Docs job reach the publish step. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
fix(sql,build): stop scalac -rewrite from dirtying git tree during re… …lease (#1545) * fix(sql): pre-format Repo.this() constructor to avoid mid-build source rewrite Scala 3's -rewrite/-no-indent scalacOptions (project/BuildHelper.scala) rewrote this indentation-style constructor to braces on first compile, since the sql module is new. That mutated a tracked file during the v0.0.48 release build, making git report a dirty tree mid-cross-build. sbt-dynver then computed a fresh SNAPSHOT+timestamp version at every settings reload instead of the clean tag version, and Central Portal's final bundle-upload step rejects SNAPSHOT versions outright -- causing the release job to fail and retry-loop until it hit the 60-minute timeout (job 29984499089). Committing the compiler's own rewritten form up front means there's nothing left to rewrite, so the tree stays clean for the whole release. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(sql): wrap Repo.this() params instead of braces to satisfy both scalafmt and scalac -rewrite Braces satisfied scalac's -rewrite/-no-indent but scalafmt's rewrite.rules = [RedundantBraces] strips them right back off, failing lint (previous commit e6882f0 broke CI lint for exactly this reason). Wrapping the `using` parameter list instead keeps the body as a same-line single expression, which both tools agree on: scalafmtCheckAll passes and no further scalac rewrite occurs on recompile (verified locally on both sql cross-targets, 3.8.3 and 3.3.7). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * build: drop -rewrite scalacOption to stop compiler from silently mutating source -rewrite paired with -no-indent auto-converts indentation-style code to braces as a side effect of running `compile` -- which is what dirtied the git tree mid-release-build and caused the v0.0.48 release failure in the first place (see PR description / prior commits on this branch). -no-indent alone (without -rewrite) still enforces brace-style, but now non-conforming code fails compilation with a clear, visible error instead of being silently rewritten on disk. This surfaces the same class of problem at normal PR-compile time instead of at release time. Verified: full `compile` across both sql cross-targets (Scala 3.8.3 and 3.3.7) plus a full-repo compile on each shows no new failures -- only 3 pre-existing, unrelated failures remain (an ambiguous import in JsonCodecDeriver.scala, and a JDK-version mismatch in a benchmark module using a macro library built for a newer JDK), both present before this change too. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
PreviousNext