The Windows installer bundles the desktop JAR from the client package (#562) - #566
Conversation
…, not from a client tree that no longer exists (#562) Every run of windows-installer.yml since 0.5.189 failed at its first real step — `cd client && ./gradlew …` against a directory #471 deleted — and read `success` at the run level because the job is non-gating. No installer has been produced since. The wheel depends on `ciris-client`, whose win_amd64 wheel carries the Compose uber-jar under `ciris_client/_artifacts/` with a manifest, and the launcher already resolves it through `ciris_client.artifact_path`. So: the Gradle setup and the UberJar/stage steps go; after `pip install` of the server wheel a step asks the client package where the JAR is; the PyInstaller spec collects `ciris_client`'s data and modules into the bundle; the stage check asserts the JAR rode along; jlink trims the JRE against that JAR. The README and the jlink script's usage follow. The job stays non-gating for this PR: its rationale ("the Windows wheel does not build") is no longer true, but the installer has not produced an artifact in months and the first green run should be watched before the job is allowed to fail main. Driven by workflow_dispatch on this branch. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 93e5f97ae3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| copy desktopApp\build\compose\jars\CIRIS-windows-*.jar ..\python\ciris_server\desktop_app\ | ||
| # 0. build + install the wheel (needs Rust + maturin); pip pulls ciris-client, | ||
| # whose win_amd64 wheel carries the desktop JAR (no Gradle, no client/ tree) | ||
| cd ..; maturin build --release -o dist-wheel; pip install (Get-ChildItem dist-wheel\*.whl) |
There was a problem hiding this comment.
When a Windows developer follows this recipe from the checkout root, the retained cd .. moves outside the repository before invoking maturin, where the project manifests and subsequent installers\windows path do not exist. Remove this directory change, which was only needed to return from the now-deleted client directory.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in c649136: the cd .. is gone — the recipe now says it runs from the repository root and moves into installers\windows only for the PyInstaller step. Also refreshed while there: the version example (0.5.38 → 0.5.203) and the pointer to a windows7-installer.yml that no longer exists.
…th 0.5.202's Windows wheel, and run 34226383277 produced the first artifact continue-on-error had been on the job since the Windows wheel could not build; under it the job failed on `cd client` on every run after #471 while the run read success. The rebuilt job just produced CIRIS-Server-Setup-0.5.203-x64.exe (117 MiB: the frozen node, the client package's 66 MB desktop JAR, a 51 MB jlink runtime). From here a failure is a failure. The step-level continue-on-error on the two CIRISCache steps stays — a cache miss is not an installer failure. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Proof run green end to end on the first try: https://github.com/CIRISAI/CIRISServer/actions/runs/34226383277
With one artifact on the record the job's |
…ns on the PR Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…nd names the workflow that exists (Codex on #566) The `cd ..` that returned from the deleted client/ step walked out of the checkout before maturin ran; the version example and the reference to a windows7-installer.yml that no longer exists are refreshed with it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
The ubuntu |
1 participant
Every run of windows-installer.yml since 0.5.189 failed at its first real
step —
cd client && ./gradlew …against a directory #471 deleted — andread
successat the run level because the job is non-gating. No installerhas been produced since.
The wheel depends on
ciris-client, whose win_amd64 wheel carries theCompose uber-jar under
ciris_client/_artifacts/with a manifest, and thelauncher already resolves it through
ciris_client.artifact_path. So: theGradle setup and the UberJar/stage steps go; after
pip installof theserver wheel a step asks the client package where the JAR is; the PyInstaller
spec collects
ciris_client's data and modules into the bundle; the stagecheck asserts the JAR rode along; jlink trims the JRE against that JAR. The
README and the jlink script's usage follow.
The job stays non-gating for this PR: its rationale ("the Windows wheel does
not build") is no longer true, but the installer has not produced an
artifact in months and the first green run should be watched before the
job is allowed to fail main. Driven by workflow_dispatch on this branch.
Proof: a
workflow_dispatchrun ofwindows-installer.ymlon this branch — https://github.com/CIRISAI/CIRISServer/actions/runs/34226383277 — the artifactciris-server-windows-installer(CIRIS-Server-Setup-0.5.203-x64.exe) is the deliverable.Not in this PR: removing the job's
continue-on-error— its stated reason (the Windows wheel does not build) is stale since 0.5.202, but the job should produce one green artifact before it may fail main. Follow-up once this run is green.🤖 Generated with Claude Code