feat(ci): re-enable Linux release builds (CPU, deb+rpm)#488
Conversation
Linux shipped briefly in March 2026 (b580189..103e98b) then was removed with the message "github runners suck." The post-mortem: standard ubuntu-22.04 hit disk-pressure during pip+PyInstaller, and a namespace custom-runner attempt proved flaky. Nothing in the app itself was the problem — the NVIDIA-package exclusions in build_binary.py (~3 GB shaved from CPU builds), the CPU-only torch install order, the PulseAudio/PipeWire audio capture code, and the Tauri deb/rpm bundle targets all still work. This restores ubuntu-22.04 to the release matrix as a CPU-only Linux build with a disk-space cleanup step (jlumbroso/free-disk-space) to address the root cause of the March failures. Ships .deb + .rpm only — AppImage was explicitly dropped in e18757b due to glibc portability issues, keeping that decision. CUDA-for-Linux is intentionally deferred to a follow-up PR: the GpuAcceleration.tsx frontend hard-codes CUDA download as Tauri-only without a Linux branch, and AMD users already get ROCm acceleration for free on a stock CPU-torch install (backend/app.py:148-160). The NVIDIA-on-Linux case is the only remaining gap and is non-blocking for a v1 Linux ship. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdded an Ubuntu 22.04 matrix entry and Ubuntu-only disk-space and diagnostics steps to the release CI; adjusted Tauri bundling args, timeout, and env vars; and bumped multiple package and Tauri versions from 0.4.1 → 0.4.2 across manifests. Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub Actions
participant Runner as Runner (ubuntu-22.04 / other)
participant Disk as FreeDiskStep
participant Env as PreBundleDiagnostics
participant TauriAction as Tauri Action
participant Bundler as Cargo/Tauri Bundler
participant Artifacts as Release Artifacts
GH->>Runner: start release job (matrix)
Runner->>Disk: (Ubuntu-only) reclaim disk / enable swap
Runner->>Env: (Ubuntu-only) print df/free/rust/cargo/tauri info
Runner->>TauriAction: run tauri-action (env vars, conditional timeout)
TauriAction->>Bundler: invoke cargo/tauri build (target: x86_64-unknown-linux-gnu)
Bundler->>Artifacts: produce bundles (deb,rpm) [createUpdaterArtifacts:false]
Artifacts-->>GH: upload/store release artifacts
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
44-53: Minor:tool-cache: falseis intentional but worth a comment; consider dropping the'namespace'branch if unused here.
- Keeping
tool-cache: falseis the right call since the job relies on preinstalled Rust/Node/Python toolchains — a brief inline note would prevent a future contributor from flipping it totrueand breaking the build.- The
contains(matrix.platform, 'namespace')branch mirrors the existing apt step, but this workflow's matrix only declares GitHub-hosted runners (nonamespace-*labels). If namespaced runners aren't planned for the release job, the branch is dead code; if they are, note thatjlumbroso/free-disk-spaceassumes a GitHub-hosted Ubuntu image layout and may no-op or error on other runner images — verify before relying on it.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 44 - 53, The workflow step "Free up disk space (ubuntu)" uses jlumbroso/free-disk-space with tool-cache: false and a conditional if: contains(matrix.platform, 'ubuntu') || contains(matrix.platform, 'namespace'); add an inline comment next to tool-cache: false explaining it's intentional because the job relies on preinstalled Rust/Node/Python toolchains, and either remove the contains(matrix.platform, 'namespace') branch if you do not plan to support namespaced/self-hosted runners for this release job, or add a note that using jlumbroso/free-disk-space on non-GitHub-hosted images may no-op or fail and should be validated before enabling namespace-labeled runners.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Line 46: The workflow uses the unpinned action reference
jlumbroso/free-disk-space@main which is a supply-chain risk; change that usage
to a specific released tag or commit SHA (e.g. replace
jlumbroso/free-disk-space@main with jlumbroso/free-disk-space@<release-tag> or
@<commit-sha>) so the job is immutable and consistent with other pinned actions
like actions/checkout@v4 and tauri-apps/tauri-action@v0.6.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 44-53: The workflow step "Free up disk space (ubuntu)" uses
jlumbroso/free-disk-space with tool-cache: false and a conditional if:
contains(matrix.platform, 'ubuntu') || contains(matrix.platform, 'namespace');
add an inline comment next to tool-cache: false explaining it's intentional
because the job relies on preinstalled Rust/Node/Python toolchains, and either
remove the contains(matrix.platform, 'namespace') branch if you do not plan to
support namespaced/self-hosted runners for this release job, or add a note that
using jlumbroso/free-disk-space on non-GitHub-hosted images may no-op or fail
and should be validated before enabling namespace-labeled runners.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 151690db-bb5e-45cd-9234-ec712ff1df01
📒 Files selected for processing (1)
.github/workflows/release.yml
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 7db1651. Configure here.
| # "github runners suck") — not a code issue, a disk-pressure one. | ||
| - name: Free up disk space (ubuntu) | ||
| if: contains(matrix.platform, 'ubuntu') || contains(matrix.platform, 'namespace') | ||
| uses: jlumbroso/free-disk-space@main |
There was a problem hiding this comment.
Unpinned third-party action in release workflow
High Severity
jlumbroso/free-disk-space@main references the mutable main branch instead of a pinned version tag or commit SHA. This job runs with contents: write permissions in a release workflow, so a compromised or force-pushed main branch of that third-party repo could inject arbitrary code that tampers with release assets or secrets. Every other action in this workflow uses a versioned tag (e.g. @v4, @v5). This needs to be pinned to a specific commit SHA or release tag.
Reviewed by Cursor Bugbot for commit 7db1651. Configure here.
| android: true | ||
| dotnet: true | ||
| haskell: true | ||
| large-packages: true |
There was a problem hiding this comment.
Disk cleanup removes LLVM then build reinstalls it
Medium Severity
large-packages: true causes the free-disk-space action to run sudo apt-get remove -y '^llvm-.*', removing all LLVM packages. The very next step then reinstalls llvm-dev via apt-get install. This wastes CI time and, more importantly, the apt-get remove of llvm-* can cascade-remove reverse dependencies that won't be automatically pulled back in when llvm-dev alone is reinstalled, potentially breaking the build.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 7db1651. Configure here.
tauri-action uses tauri.conf.json's version to name the release, so pushing v0.4.2 as a tag alone was insufficient — the workflow was still trying to publish to v0.4.1 (immutable) and failing. Bumps all workspace package.json files, Cargo.toml, Cargo.lock, and tauri.conf.json. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The first v0.4.2 attempt hung inside tauri-action at the bundling stage on ubuntu-22.04 for ~28 min with no output. Same failure mode that drove the March 2026 removal (commit 103e98b). Without visibility we're guessing — probable causes include linuxdeploy/AppImage download stalls (despite --bundles deb,rpm), cargo link on a cold cache, or disk pressure during the final link step. - timeout-minutes: 30 on tauri-action for Ubuntu (45 min elsewhere) — fail fast with logs instead of waiting out the 6hr job timeout. - --verbose added to the Linux build args so cargo streams progress. - CARGO_TERM_VERBOSE + RUST_BACKTRACE=1 exported on tauri-action. - New 'Disk / environment snapshot' step dumps df/free/tool versions right before the tauri step so we can correlate with any later OOM/ENOSPC failure. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/release.yml (2)
199-214: Verbose logging + 30 min Ubuntu cap: reasonable, watch log size.
CARGO_TERM_VERBOSE=trueplus--verboseinmatrix.args(line 30) double up on cargo verbosity and, combined withRUST_BACKTRACE=1, will produce large logs — usually fine, but GitHub truncates step logs past ~4 MB which can hide the actual failure you're trying to catch. If you hit truncation, consider dropping one of the two verbose toggles or switchingRUST_BACKTRACEtofullonly when reproducing locally.Also: the 30-minute cap is tight if the PyInstaller-bundled server is large and linuxdeploy has to stage it; if the first green run lands near the cap, bump to 40.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 199 - 214, The workflow currently sets CARGO_TERM_VERBOSE: "true" while matrix.args also passes --verbose (refer to CARGO_TERM_VERBOSE and matrix.args) and sets RUST_BACKTRACE: "1", which can create oversized logs; remove the duplicate verbosity by either unsetting CARGO_TERM_VERBOSE or removing --verbose from matrix.args, and change RUST_BACKTRACE usage so it is not set globally (use RUST_BACKTRACE=full only in local repros or gated by an env like DEBUG_RUN) to reduce log volume. Also increase the Ubuntu timeout-minutes conditional (the expression setting timeout-minutes when contains(matrix.platform, 'ubuntu')) from 30 to 40 to avoid cutting off long linuxdeploy/PyInstaller runs.
45-45:contains(matrix.platform, 'namespace')is dead code.The matrix (lines 17–32) has no
namespace-prefixed platform, so this half of the OR never fires. Same pattern is repeated on lines 56, 75, 157, and 200. Either drop it everywhere, or add a short comment that it's a forward-compat hook for Namespace.so runners so future readers don't have to guess.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml at line 45, The conditional contains(matrix.platform, 'namespace') is dead code in .github/workflows/release.yml; either remove that clause from every if that uses it (e.g., the if expressions containing contains(matrix.platform, 'namespace')) or keep it but add a short inline comment next to the expression explaining it’s a forward-compatibility hook for Namespace.so runners so future readers know it’s intentional; update all repeated occurrences of contains(matrix.platform, 'namespace') in the file to be consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 199-214: The workflow currently sets CARGO_TERM_VERBOSE: "true"
while matrix.args also passes --verbose (refer to CARGO_TERM_VERBOSE and
matrix.args) and sets RUST_BACKTRACE: "1", which can create oversized logs;
remove the duplicate verbosity by either unsetting CARGO_TERM_VERBOSE or
removing --verbose from matrix.args, and change RUST_BACKTRACE usage so it is
not set globally (use RUST_BACKTRACE=full only in local repros or gated by an
env like DEBUG_RUN) to reduce log volume. Also increase the Ubuntu
timeout-minutes conditional (the expression setting timeout-minutes when
contains(matrix.platform, 'ubuntu')) from 30 to 40 to avoid cutting off long
linuxdeploy/PyInstaller runs.
- Line 45: The conditional contains(matrix.platform, 'namespace') is dead code
in .github/workflows/release.yml; either remove that clause from every if that
uses it (e.g., the if expressions containing contains(matrix.platform,
'namespace')) or keep it but add a short inline comment next to the expression
explaining it’s a forward-compatibility hook for Namespace.so runners so future
readers know it’s intentional; update all repeated occurrences of
contains(matrix.platform, 'namespace') in the file to be consistent.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d10643ac-b867-4173-9bc3-daa224de2810
📒 Files selected for processing (1)
.github/workflows/release.yml
…loy hang) Round-2 diagnosis from the v0.4.2 attempt: cargo finished in 3m 55s, .deb and .rpm were bundled within 22s, then the step hung silently for 25 min until our 30-min watchdog killed it — no further log lines. tauri.conf.json has `createUpdaterArtifacts: "v1Compatible"`. On Linux the v1-compatible updater path wants a .AppImage.tar.gz, which means downloading linuxdeploy-x86_64.AppImage from GitHub at build time. That download is the silent blocker — same signature as the March 2026 "github runners suck" removal (commit 103e98b). Fix: pass `--config {"bundle":{"createUpdaterArtifacts":false}}` on the Linux build only. Mac/Windows continue to produce signed updater artifacts as before. Linux users update via apt/dnf; Tauri in-app auto-update for Linux can come later (and would require shipping AppImage alongside deb/rpm). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 201-207: The 30-minute timeout on the tauri bundling step (the
step using tauri-apps/tauri-action@v0.6) is too short for a cold Ubuntu build;
update the timeout-minutes expression so Ubuntu (or any linux/namespace matrix
entries) uses 45 minutes instead of 30 for initial runs (e.g., change the
conditional that sets timeout-minutes for the tauri-action step to return 45 for
Ubuntu/linux), and optionally document or gate a later reduction once a baseline
build time is observed.
- Around line 29-39: Replace the inline JSON passed to the tauri CLI via the
args value (the --config {"bundle":{"createUpdaterArtifacts":false}} string)
with an explicit Linux-specific config file and point --config at that file;
create src-tauri/tauri.conf.linux.json containing {"bundle":
{"createUpdaterArtifacts": false}} and change the args value in the workflow to
use --config tauri.conf.linux.json (keeping the other flags intact), then run
the Ubuntu job and confirm the tauri step (via --verbose output) shows
createUpdaterArtifacts overridden and no linuxdeploy download occurs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5c015876-8cfe-4878-a33d-cd814cf19e8c
📒 Files selected for processing (1)
.github/workflows/release.yml
| - platform: "ubuntu-22.04" | ||
| # --config override disables updater-artifact generation on Linux. | ||
| # tauri.conf.json has createUpdaterArtifacts: "v1Compatible" which | ||
| # on Linux wants to synthesize a .AppImage.tar.gz by downloading | ||
| # linuxdeploy at build time — this is what silently hangs CI | ||
| # (see v0.4.2 round 2, 25 min of no output after rpm bundling). | ||
| # We ship deb+rpm only; Linux users update via apt/dnf, not the | ||
| # Tauri in-app updater. | ||
| args: '--target x86_64-unknown-linux-gnu --bundles deb,rpm --verbose --config {"bundle":{"createUpdaterArtifacts":false}}' | ||
| python-version: "3.12" | ||
| backend: "pytorch" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
tauri-apps/tauri-action how are args passed to tauri CLI shell quoting JSON --config
💡 Result:
In the tauri-apps/tauri-action GitHub Action, arguments are passed to the Tauri CLI via the args input, which is parsed into an array using the string-argv library. This library splits the input string on spaces while respecting quotes, so paths with spaces must be quoted. To pass --config with a JSON file path: with: args: '--config "path/to/tauri.conf.json" --other-arg value' The Tauri CLI's --config (or -c) flag accepts either: - A file path (relative paths resolve relative to projectPath if set) - An inline JSON string When a path is provided, Tauri first attempts to parse it as JSON (expecting inline config), and falls back to reading the file if parsing fails—this produces the "Couldn't parse --config flag as inline JSON. This is not an error if it's a file path." message, which is normal. Examples from docs and issues: - args: '--target aarch64-apple-darwin' - args: "--config tauri.conf.linux.json" (fails if path has spaces or relative path issues) - args: "-c src-tauri/tauri.conf.linux.json" For paths with spaces, use double quotes around the path value. Paths are resolved relative to the project root (projectPath), and the action detects/supports --config for config merging. Official docs confirm: "Additional arguments to the current tauri build command. Relative paths in the --config flag will be resolved relative to projectPath."
Citations:
- 1: https://github.com/tauri-apps/tauri-action/blob/0b300d3e/README.md
- 2: https://github.com/tauri-apps/tauri-action
- 3: https://github.com/tauri-apps/tauri-action/
- 4: https://github.com/tauri-apps/tauri-action/blob/dev/README.md
- 5: https://github.com/tauri-apps/tauri-action/blob/0b300d3e/src/index.ts
- 6: https://github.com/tauri-apps/tauri-action/blob/dev/action.yml
- 7: https://github.com/tauri-apps/tauri-action/blob/0b300d3e/src/build.ts
- 8: https://github.com/tauri-apps/tauri-action/blob/0b300d3e/src/config.ts
- 9: Config arguments don't seem to work tauri-apps/tauri-action#879
- 10: actions does not read config file by
--configflag tauri-apps/tauri-action#712
Consider using a separate config file instead of inline JSON in --config for clarity.
The embedded JSON in --config {"bundle":{"createUpdaterArtifacts":false}} is wrapped in YAML single quotes, which preserves the literal double-quote characters. The tauri-action GitHub Action uses the string-argv library to parse the args input, which respects quoted strings and prevents brace expansion, so the JSON should parse correctly. Tauri CLI officially supports inline JSON in the --config flag and will parse it as expected.
However, for clarity and maintainability, using a separate config file is recommended:
- Create
src-tauri/tauri.conf.linux.jsonwith the Linux-specific overrides - Pass
args: '--target x86_64-unknown-linux-gnu --bundles deb,rpm --verbose --config tauri.conf.linux.json'
This avoids any quoting subtleties and makes the configuration explicit.
In any case, confirm in the first Ubuntu run that the Tauri step logs show createUpdaterArtifacts actually being overridden (via --verbose output) and that no linuxdeploy download is attempted, to ensure the config override is working as intended.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yml around lines 29 - 39, Replace the inline JSON
passed to the tauri CLI via the args value (the --config
{"bundle":{"createUpdaterArtifacts":false}} string) with an explicit
Linux-specific config file and point --config at that file; create
src-tauri/tauri.conf.linux.json containing {"bundle": {"createUpdaterArtifacts":
false}} and change the args value in the workflow to use --config
tauri.conf.linux.json (keeping the other flags intact), then run the Ubuntu job
and confirm the tauri step (via --verbose output) shows createUpdaterArtifacts
overridden and no linuxdeploy download occurs.
| # Linux hang watchdog: previous releases silently wedged inside tauri | ||
| # bundling (possibly linuxdeploy/AppImage download, possibly cargo link). | ||
| # Cap the step at 30 min so we get logs instead of waiting out the 6hr | ||
| # job timeout. Other platforms historically complete in ~25 min, so 45 | ||
| # is comfortable. | ||
| - uses: tauri-apps/tauri-action@v0.6 | ||
| timeout-minutes: ${{ (contains(matrix.platform, 'ubuntu') || contains(matrix.platform, 'namespace')) && 30 || 45 }} |
There was a problem hiding this comment.
30-minute timeout may be tight for the first Linux build.
The Ubuntu job does a cold Rust build plus deb + rpm bundling (no Rust cache hit on first run, and swatinem/rust-cache won't have a baseline). If tauri-action is capped at 30 min, the initial release can trip the watchdog for a non-hang reason and mask whether the createUpdaterArtifacts:false fix actually worked. Consider starting at 45 min for Ubuntu too and tightening later once you have a baseline, or only applying the 30-min cap on re-runs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yml around lines 201 - 207, The 30-minute timeout
on the tauri bundling step (the step using tauri-apps/tauri-action@v0.6) is too
short for a cold Ubuntu build; update the timeout-minutes expression so Ubuntu
(or any linux/namespace matrix entries) uses 45 minutes instead of 30 for
initial runs (e.g., change the conditional that sets timeout-minutes for the
tauri-action step to return 45 for Ubuntu/linux), and optionally document or
gate a later reduction once a baseline build time is observed.
Review feedback on the Linux release workflow: 1. `jlumbroso/free-disk-space@main` was an unpinned ref in a job that runs with `contents: write` and handles signing secrets. Pin to the v1.3.1 commit SHA so a force-push or repo compromise can't inject arbitrary code into our release flow. 2. `large-packages: true` runs `apt-get remove '^llvm-.*'`, wiping LLVM just before the next step installs `llvm-dev`. That wastes CI time and risks cascade-removal of reverse deps that won't be pulled back in by `llvm-dev` alone. The remaining toggles (android, dotnet, haskell, swap-storage) already clear ~20 GB, which is enough headroom for the Python + torch + PyInstaller build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
Brings Linux back to the release matrix. Linux shipped briefly in March 2026 (
b580189..103e98b) and was pulled out with the commit message literally reading "github runners suck" — the failure was runner disk pressure during pip+PyInstaller, not anything in the app code.Change:
ubuntu-22.04to the release matrix with--target x86_64-unknown-linux-gnu --bundles deb,rpm.jlumbroso/free-disk-spacestep to prune preinstalled toolchains (Android SDK, .NET, Haskell GHC, large APT packages, swap) — reclaims ~25 GB, which should address the root cause of the March failures..deb+.rpm.What's intentionally NOT in this PR:
e18757bdue to glibc portability issues. Keeping that decision.app/src/components/ServerSettings/GpuAcceleration.tsxcurrently hard-codes the CUDA download path as Tauri-only without a Linux-specific branch, and AMD GPU users already get acceleration through ROCm on a stock CPU-torch install (backend/app.py:148-160). NVIDIA-on-Linux is the only remaining gap and is non-blocking for a v1 Linux ship./download?platform=linuxback to "download the asset" (currently redirects to/linux-install). Follow-up PR after first green tag.What's already in place (verified against current main):
build_binary.py:311-327) → ~3 GB shaved off final binary.requirements.txton Linux (release.yml:74-77) → avoids nvidia transitives getting frozen in.backend/app.py:148-160) + AMD env vars set unconditionally (lines 38-42).tauri/src-tauri/src/audio_capture/linux.rs).targets: "all"→ produces.deb/.rpm/.AppImageautomatically on Linux (we filter with--bundles).libwebkit2gtk-4.1-dev,libappindicator3-dev,librsvg2-dev,patchelf,llvm-dev,libasound2-dev(release.yml:55-59) — was latent; now fires.Test plan
workflow_dispatch) on a test tag to validate end-to-end before a real release.ubuntu-22.04job reaches the "Build Python server" step without running out of disk.tauri-actionproduces.deband.rpmin the tauri-apps release..debon a clean Ubuntu 22.04 VM, launch the app, generate with a CPU-compatible engine (LuxTTS / Kokoro / Chatterbox CPU).Follow-ups after green
landing/src/app/download/page.tsxLinux branch back to asset download (don't force-redirect to/linux-install).landing/src/app/linux-install/page.tsxcopy — remove "CI issues" language.build-cuda-linuxcompanion job mirroringbuild-cuda-windows, plus a Linux-aware download path inGpuAcceleration.tsx.🤖 Generated with Claude Code
Note
Medium Risk
Changes the release workflow matrix and runner setup, which can affect tagged release production and may fail due to GitHub runner environment/disk variability.
Overview
Re-enables Linux artifacts in the release workflow by adding an
ubuntu-22.04job to the release matrix and passing--bundles deb,rpmfor packaging.Adds an Ubuntu-only disk reclamation step (
jlumbroso/free-disk-space) before dependency installs to reduce runner disk-pressure during pip/PyInstaller/Torch builds.Reviewed by Cursor Bugbot for commit 7db1651. Configure here.
Summary by CodeRabbit