Tar JVM build outputs for artifact upload, extract before packaging verify, derive iphoneos SDK_NAME from xcrun, and skip appimagetool permission checks on CI.
Co-authored-by: Cursor <cursoragent@cursor.com>
Build the KMP framework with plain Gradle logs before xcodebuild, skip the Xcode Gradle script phase, and include gitignored build outputs in jvm-compile-outputs artifacts.
Co-authored-by: Cursor <cursoragent@cursor.com>
Stamp AppUserModel IDs on installer shortcuts to match the desktop app, embed proper ICOs in launchers, derive beta setup names from versionName, and sync/copy helpers for the Windows VM workflow.
Co-authored-by: Cursor <cursoragent@cursor.com>
Compose Desktop's AbstractProguardTask builds ProGuard's -libraryjars by
walking <javaHome>/jmods and nothing else. Adoptium stopped shipping the
jmods/ directory in JDK 25 archives (verified: 0 jmods entries in both the
linux/x64 and macOS/aarch64 Temurin 25.0.4.1 tarballs, vs 71 for Temurin
17), so on the runners the desktop packaging JDK resolves to
/usr/lib/jvm/temurin-25-jdk-amd64 and ProGuard gets no JDK whatsoever.
Every class then fails to resolve java.lang.Object — 1.3M
"can't find superclass or interface java.lang.Object" warnings, followed by
"Please correct the above warnings first".
This is why the Java 25 toolchain bump broke every release while the
v1.2.0-beta release on the toolchain 17 build kept working, and why a local
build with the JetBrains Runtime (which does ship jmods) succeeded while CI
did not. ProGuard's version was never the cause; 7.10.0 was still kept
because it is what understands this project's Kotlin 2.4 metadata.
Install Zulu 25 (still ships jmods) in the desktop-proguard job and export
it as FROMCHAT_PACKAGING_JDK; setup-java runs before Temurin 17 so JAVA_HOME
stays on 17 for Gradle and the Android build. resolvePackagingJdkHome() now
warns loudly when the JDK it picks has no jmods/, instead of leaving it to
ProGuard's wall of warnings.
Use setup-java's `path` output for FROMCHAT_PACKAGING_JDK
setup-java@v5 names the installed JDK's location `path`, not `java-path`
(the v4 name), so the beta4 run exported an empty value, fell back to the
jmods-less /usr/lib/jvm/temurin-25-jdk-amd64 and failed with the same
"can't find superclass or interface java.lang.Object" wall of warnings.
The Gradle-side guard added in b0159eb correctly named the offending JDK
in the beta4 log, which is what pointed at the empty export.
Give the Linux packaging jobs a jmods-capable JDK too
beta5 proved the ProGuard fix: Build JAR passed in 9m35s, and Windows
(x64 + ARM) and macOS (arm64 + Intel) all packaged successfully. Only the
two Linux jobs failed, at :app:desktop:createRuntimeImage — jlink exits 1
because jlink defaults its --module-path to <javaHome>/jmods, the same
directory ProGuard needs. So the jmods gap bites twice: ProGuard degrades
into a wall of warnings, jlink just dies.
macOS/Windows runners happen to resolve a JDK 25 that still ships jmods;
ubuntu-latest's /usr/lib/jvm only has the jmods-less Temurin 25. Point the
Linux jobs at Zulu 25 via the setup action's desktop-jdk input, and stop
the packaging step's `export FROMCHAT_PACKAGING_JDK="$JAVA_HOME"` from
clobbering it with Temurin 17 (hence ${VAR:-$JAVA_HOME}).
Also widen the Gradle guard to name jlink, since that is what actually
fails on a jmods-less JDK during packaging.
Fix two Windows ARM64 failures: JDK-8371740 and a needless JDK download
Neither is related to the jmods work; both were visible only on the
windows-11-arm runner.
1. Gradle hung at build shutdown. The runner's ambient JAVA_HOME is Temurin
21.0.12 aarch64, and JDK-8371740 — a LinkedTransferQueue race fixed only
in JDK 26 — makes Gradle on Windows ARM64 hang whenever it runs on JDK
21+, failing the build after the installer was already written with
"Timeout waiting for concurrent jobs to complete". Gradle's own repo and
linroid/Ketch both carry workarounds for this. Pin the Gradle JVM to 17,
which is what the x64 job already does; Adoptium ships no Windows aarch64
17, hence the new `java-distribution` input and zulu there. Packaging is
unaffected: resolvePackagingJdkHome() rejects 17 as too old and falls back
to the Java 25 toolchain JDK for jpackage.
2. "Ensure ARM64 packaging JDK" stalled for minutes and looked hung. The
script only scanned C:\Program Files\Eclipse Adoptium, but hosted ARM64
runners ship their ARM64 Temurin 21 under the hostedtoolcache, so the scan
missed it and fell through to downloading a ~180 MB JDK via
Invoke-WebRequest + Expand-Archive. Re-running the job showed it still
installing 3m24s later. Accept JAVA_HOME when it reports os.arch=aarch64 —
the script's own comments already call Java 21 good enough as the Gradle
daemon JVM.
Stop the Gradle build cache from being invalidated on every release
Two independent defects, both found while a release sat at 8.83 GB of the
10 GB per-repo cache limit with entries being evicted.
1. set-version rewrote build.gradle.kts with sed on every run, and that file
is hashed into the Gradle build-cache key — so each release produced a
brand-new key and orphaned the previous one. The repo inventory showed the
damage: windows-package-x64, macos-x64 and windows-package-arm64 each had
two ~1.1 GB entries differing only in that hash. build.gradle.kts now reads
-PversionName/-PversionCode (injected as ORG_GRADLE_PROJECT_* by
set-version) and keeps its previous values as defaults, so local builds are
unchanged. Types stay String/Integer for the `as Int`/`as String` consumers
in app/android and app/shared. Side benefit: hash-release-build-inputs also
hashes build.gradle.kts, so the "inputs unchanged" marker no longer churns
per version either.
2. Every desktop scope archived the Android build dirs (never built there)
plus the final installers, the exported ProGuard jars, the jpackage runtime
image and the ProGuard temp output — all regenerated for each version, and
together the bulk of a ~1.7 GB entry. Those paths are now excluded, which
is what kept the repo over the limit and into eviction (GitHub evicts by
oldest last-accessed once the limit is hit).
Restore and save path lists stay in sync: actions/cache silently skips the save
when they differ.
Cross-tag reuse is NOT addressed here and cannot be: per the docs, a run for one
tag cannot read another tag's cache, and the automatic retry against the default
branch is a no-op for us because main has no app/desktop module to warm it.
Stage each packaging host's own Skiko/JavaFX natives
The beta7 desktop builds cannot start. Both failures the user reported
(macOS arm64 and Linux arm64) are the same bug:
ERROR: [Desktop] uncaught on main Failed to loade library
.../libskiko-macos-arm64.dylib
Caused by: java.lang.UnsatisfiedLinkError: Can't load library
ProGuard runs once, on ubuntu-latest, and its output is shipped to every
packaging job. But the Compose desktop runtime classpath is host-specific:
that single ProGuard run froze in skiko-awt-runtime-linux-x64 and
javafx-*-27-linux, and nothing for any other target. Inspecting the published
macOS arm64 DMG confirmed it — 140 jars, the entire ProGuard set, with
skiko-awt-runtime-linux-x64 as the only Skiko runtime and no
libskiko-*-arm64 anywhere in the bundle, plus no JavaFX natives either. The
macOS x64 build is broken the same way; Linux x64 is the only target that
happened to match, and the Windows installers shipped Linux natives too.
stageCiPrebuiltProguard now also stages the packaging host's own natives
(skiko-awt-runtime-<os>-<arch>, javafx-*-<os>-<arch>) from its resolved
runtimeClasspath. Skiko and JavaFX each pick their library by os/arch, so the
foreign Linux copies stay inert and cost only some bundle size. The task
fails loudly if a host resolves no natives at all.
Verified locally end-to-end with a prebuilt-ProGuard packaging run:
Contents/app/libskiko-macos-arm64.dylib (21.3 MB) is now present, which is
the exact path Skiko failed to load before.
Keep ProGuard's output cached in the one scope that runs it
Follow-up to 0e7b181, which excluded compose/tmp from every desktop scope
to shrink the cache entries. That was too blunt for the build-jar scope:
compose/tmp/main-release/proguard holds proguardReleaseJars' *output*, so
without those jars Gradle can never consider the task up-to-date and
re-runs its ~8 minutes on every re-run of a tag.
Split the non-android path list in two. build-jar keeps compose/tmp; the
packaging scopes drop it, because they never run ProGuard — they stage the
Build JAR artifact's jars instead, so their copy is a redundant 122 MB.
jvmToolchain(25) (f89619a) compiles classes to class file 69, but
resolvePackagingJdkHome() accepted any JDK that shipped jpackage. On Windows
ARM64 the candidate list hardcoded jdk-21-arm64 first and
ensure-windows-arm64-jdk.cmd provisioned Temurin 21; on macOS the first
candidate was Adoptium 17. jpackage then bundled a Java 17/21 runtime and the
installed app died at launch with UnsupportedClassVersionError on the hidden
launcher's stderr (invisible: GUI subsystem, no error dialogs).
CI hit this too: setup-java-gradle installs Temurin 17 and the workflows
export FROMCHAT_PACKAGING_JDK="$JAVA_HOME", which the resolver returned
verbatim — so the x64 installer built by desktop-windows-x64.yml was broken
on launch.
- build.gradle.kts: version-gate FROMCHAT_PACKAGING_JDK / JAVA_HOME /
candidate JDKs to >= desktopJvmTarget (25) with a warning, then fall back to
the Gradle-provisioned toolchain JDK (recursive .gradle/jdks scan).
- ensure-windows-arm64-jdk.cmd: prefer an installed jdk-25* or the
Gradle-provisioned Java 25 toolchain JDK; Temurin 21 remains only the
last-resort daemon JVM.
Ported from c53b54b, minus ensure-windows-x64-jdk.cmd and diag-launch.ps1:
this branch has no packageWindowsX64 path to feed, and diag-launch.ps1 is
machine-specific and unreferenced.
Verified on macOS: createDistributable now bundles JAVA_VERSION 25.0.4.1,
matching class file 69, where a previous build had bundled 17.0.19.
Split Windows builds into shared x64 prep and arch-specific packaging, add comprehensive caching, verification scripts, and a PR smoke workflow.
Co-authored-by: Cursor <cursoragent@cursor.com>
Fix release-smoke workflow YAML syntax error.
Co-authored-by: Cursor <cursoragent@cursor.com>
Fix CI smoke test compile scope and PE fixture size.
Co-authored-by: Cursor <cursoragent@cursor.com>
denis0001-dev ·