Skip to content

fix(ci): correct Tauri build artifact paths to workspace target/#570

Merged
Detair merged 1 commit into
mainfrom
fix/tauri-artifact-paths
May 13, 2026
Merged

fix(ci): correct Tauri build artifact paths to workspace target/#570
Detair merged 1 commit into
mainfrom
fix/tauri-artifact-paths

Conversation

@Detair

@Detair Detair commented May 13, 2026

Copy link
Copy Markdown
Owner

Summary

Bug: tauri-build.yml and release.yml both reference client/src-tauri/target/... for artifact uploads, but the Cargo workspace's actual target directory is at the repo root (target/...). The client/src-tauri crate is a workspace member of the root workspace.

Effect:

  • Tauri Build workflow: builds succeed and Tauri bundles all platform artifacts (Kaiku_0.1.0_amd64.deb/.rpm/.AppImage/.msi/.exe/.dmg/.app) at the real path — but the actions/upload-artifact glob never matches, silently producing 0 artifacts per run. No client downloads have ever been distributed via CI.
  • Release workflow: same paths plus working-directory: client/src-tauri/target for codesign/notarize. Latent bug — would have failed on the first v* tag push.

What's actually built (from CI logs, run 25821667446)

target/x86_64-unknown-linux-gnu/release/bundle/deb/Kaiku_0.1.0_amd64.deb
target/x86_64-unknown-linux-gnu/release/bundle/rpm/Kaiku-0.1.0-1.x86_64.rpm
target/x86_64-unknown-linux-gnu/release/bundle/appimage/Kaiku_0.1.0_amd64.AppImage

What the workflow was looking for:

client/src-tauri/target/x86_64-unknown-linux-gnu/release/bundle/deb/*.deb

Fix

Sed across the 10 occurrences in both files: client/src-tauri/target/target/. Verified locally: .cargo/config.toml has no custom target-dir override; Tauri builds in past runs wrote artifacts to the workspace-root target/.

Test plan

  • grep -c "client/src-tauri/target" in both files → 0 (verified after fix)
  • CI passes on this PR
  • After merge: trigger a fresh Tauri Build on main (e.g., gh workflow run "Tauri Build" --ref main) — artifacts should appear in the run's "Artifacts" section
  • Then a v0.1.0-beta.X tag push exercises release.yml and creates a GitHub Release with binaries attached

🤖 Generated with Claude Code

Tauri Build and Release workflows both reference `client/src-tauri/
target/...` for artifact uploads, but the Cargo workspace's actual
target directory is at the repo root (`target/...`) because
`client/src-tauri` is a workspace member of the root workspace.

Effect of the bug:
- Tauri Build workflow: builds were successful and Tauri actually
  bundled `Kaiku_0.1.0_amd64.deb`/`.rpm`/`.AppImage`/`.msi`/`.exe`/
  `.dmg`/`.app` at the real path, but the `actions/upload-artifact`
  glob never matched, silently producing 0 artifacts per run. All
  recent Tauri Build runs on `main` show "total: 0" in the artifacts
  list — no client downloads have ever been distributed via CI.
- Release workflow: same paths plus `working-directory: client/src-
  tauri/target` for the codesign/notarize steps. Latent bug — would
  fail on the first `v*` tag push.

Fix: 10 path occurrences across the two files, swapped to `target/`
to match the workspace layout. Verified locally that
`.cargo/config.toml` has no custom `target-dir` override and Tauri
build logs from past runs (e.g., run 25821667446) confirm the
artifacts are written to the workspace-root `target/`.

After this merges, a fresh Tauri Build on main will upload the
`.deb`/`.rpm`/`.AppImage`/`.msi`/`.exe`/`.dmg`/`.app` artifacts to
the workflow run, downloadable from the Actions UI or via `gh run
download`. Pushing a `v*` tag will then create a real GitHub
Release with the binaries attached.

Caught while investigating "where are the client downloads?".

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Detair Detair merged commit ce25e81 into main May 13, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant