fix(ci): add APPIMAGE_EXTRACT_AND_RUN to build-linux-amd64 #37

sarman · 2026-04-13T01:57:08Z

sarman commented

2026-04-13 01:57:08 +00:00

Problem

linuxdeploy is itself an AppImage. Tauri downloads it to bundle the .AppImage artifact, then tries to execute it directly inside the Docker container. Docker containers have no FUSE support, so the AppImage cannot mount itself — causing failed to run linuxdeploy.

Fix

Set APPIMAGE_EXTRACT_AND_RUN=1 on the Build step of build-linux-amd64. This env var tells linuxdeploy (and any AppImage tool) to extract its squashfs payload to a temp directory and run from there instead of mounting via FUSE.

build-linux-arm64 already had this set — it was simply missing from the amd64 job.

Test plan

Re-run auto-tag.yml after merge — build-linux-amd64 should produce .deb, .rpm, and .AppImage artifacts

## Problem `linuxdeploy` is itself an AppImage. Tauri downloads it to bundle the `.AppImage` artifact, then tries to execute it directly inside the Docker container. Docker containers have no FUSE support, so the AppImage cannot mount itself — causing `failed to run linuxdeploy`. ## Fix Set `APPIMAGE_EXTRACT_AND_RUN=1` on the Build step of `build-linux-amd64`. This env var tells linuxdeploy (and any AppImage tool) to extract its squashfs payload to a temp directory and run from there instead of mounting via FUSE. `build-linux-arm64` already had this set — it was simply missing from the amd64 job. ## Test plan - [ ] Re-run `auto-tag.yml` after merge — `build-linux-amd64` should produce `.deb`, `.rpm`, and `.AppImage` artifacts

sarman added 1 commit 2026-04-13 01:57:09 +00:00

fix(ci): add APPIMAGE_EXTRACT_AND_RUN to build-linux-amd64

Test / rust-fmt-check (pull_request) Successful in 13s

Details

Test / rust-clippy (pull_request) Successful in 3m47s

Details

PR Review Automation / review (pull_request) Successful in 4m11s

Details

Test / frontend-typecheck (pull_request) Successful in 1m36s

Details

Test / frontend-tests (pull_request) Successful in 1m26s

Details

Test / rust-tests (pull_request) Successful in 5m30s

Details

27a46a7542

linuxdeploy is itself an AppImage. Running it inside a Docker container
requires APPIMAGE_EXTRACT_AND_RUN=1 so it extracts and runs its payload
directly rather than relying on FUSE (unavailable in containers).
Already set on build-linux-arm64 — missing from the amd64 job.

sarman reviewed 2026-04-13 02:01:20 +00:00

sarman left a comment

🤖 Automated PR Review:\n\n### 1) Summary
This PR adds the environment variable APPIMAGE_EXTRACT_AND_RUN=1 to the Linux AMD64 build step in .gitea/workflows/auto-tag.yml. The intent appears to be enabling AppImage runtime extraction mode (used by tools like appimagetool or AppImageLauncher) during the Tauri build process—likely to avoid sandboxing issues or ensure compatibility when the resulting AppImage is executed in certain CI or testing environments.

However, the change is likely incorrect or at least incomplete, as APPIMAGE_EXTRACT_AND_RUN is not a standard Tauri or Electron build-time environment variable, and its placement in the workflow is ambiguous in terms of when and for which process it should take effect.

2) Bugs / Errors

❌ Misplaced or ineffective environment variable

APPIMAGE_EXTRACT_AND_RUN is not a Tauri build flag. According to AppImage documentation, APPIMAGE_EXTRACT_AND_RUN is an environment variable that must be set in the runtime environment of the AppImage itself (e.g., by the user or system launching the AppImage), not during the build process.
Setting it at build time (as done here) has no effect on the generated AppImage — it only affects the execution of an already-built AppImage.
In fact, Tauri’s tauri build does not use or propagate this variable into the AppImage metadata or wrapper script.

⚠️ Potential confusion with `APPIMAGE_EXTRACT_AND_RUN` vs `APPIMAGE_EXTRACT_AND_RUN=1`

Even if the variable were used at runtime, the correct value is typically APPIMAGE_EXTRACT_AND_RUN=1 (as used), but its purpose is to force extraction to a temporary directory and run from there — useful for read-only filesystems or sandboxed environments (e.g., Flatpak, some CI runners).
However, this is not a build-time concern, and setting it in the CI build step won’t make the AppImage behave this way automatically.

🛠️ Likely intended alternative: `TAURI_LINUX_APPIMAGE_EXTRACT_AND_RUN`?

Tauri does support a build-time config option:

"tauri": {
  "bundle": {
    "linux": {
      "appimage": {
        "extract-and-run": true
      }
    }
  }
}

or via CLI flag:

tauri build -- --extract-and-run

(Note: as of Tauri v1/v2, the flag may be named --extract-and-run or --appimage-extract-and-run depending on version.)

🔍 Check Tauri version & docs:

In Tauri v1.5+, the correct CLI flag is --extract-and-run for tauri build.
In Tauri v2, it’s part of the appimage bundle config (see Tauri v2 docs).

➡️ Conclusion: The PR likely should have added --extract-and-run to the npx tauri build command, not set an env var.

3) Security Issues

🔒 No direct security vulnerabilities

Setting APPIMAGE_EXTRACT_AND_RUN=1 in CI is low-risk (it’s ignored), but:
- If misused at runtime, APPIMAGE_EXTRACT_AND_RUN can increase attack surface (e.g., by extracting to world-writable /tmp), but this is irrelevant here since it’s set only during build.

⚠️ Indirect risk: Misconfiguration leads to broken AppImages

If the team assumes this env var fixes sandboxing issues in CI but it doesn’t, they may deploy broken AppImages to users or miss real fixes (e.g., missing AppArmor rules, incorrect permissions, or missing --extract-and-run in the actual bundle config).

4) Best Practices

✅ Correct placement & scope

Environment variables should be scoped to the process that needs them.
- Here, env: is defined at the step level, which means it applies to the run: command (npm ci, npx tauri build).
- But since APPIMAGE_EXTRACT_AND_RUN is not used by npm, node, or tauri build, it’s wasted.

✅ Prefer declarative config over env vars

AppImage behavior (like extract-and-run) should be configured in tauri.conf.json (v1) or tauri.conf.json5 (v2), not via CI env vars.
This makes the behavior reproducible locally and documented.

✅ Use explicit CLI flags if needed

If CI must override config, use:

run: |
  npm ci --legacy-peer-deps
  CI=true npx tauri build --target x86_64-unknown-linux-gnu -- --extract-and-run

(Note the -- to pass args to Tauri, not npm.)

✅ Document the intent

Add a comment explaining why this flag is needed (e.g., “Required for CI runners with restricted /tmp” or “Workaround for AppImage sandboxing in GitHub/Gitea Actions”).

✅ Suggested Fix

Replace the env: block with the correct Tauri CLI flag and add a clarifying comment:

       - name: Build
-        env:
-          APPIMAGE_EXTRACT_AND_RUN: "1"
+        # Enable AppImage extraction-at-runtime to avoid sandbox issues in CI runners
+        # See: https://docs.appimage.org/reference/manifest.html#environment-variables
         run: |
           npm ci --legacy-peer-deps
-          CI=true npx tauri build --target x86_64-unknown-linux-gnu
+          CI=true npx tauri build --target x86_64-unknown-linux-gnu -- --extract-and-run

🔔 Verify first: Ensure your Tauri version supports --extract-and-run. For Tauri v1.5+, it does. For earlier versions, use the config file instead.

Alternatively (and more robustly), configure it in src-tauri/tauri.conf.json:

{
  "tauri": {
    "bundle": {
      "linux": {
        "appimage": {
          "extract-and-run": true
        }
      }
    }
  }
}

Then keep the CI step simple:

- name: Build
  run: |
    npm ci --legacy-peer-deps
    CI=true npx tauri build --target x86_64-unknown-linux-gnu

Final Recommendation

Reject this PR as-is.

The change is ineffective and misleading.
Replace with either:
1. A config-based fix (extract-and-run: true), or
2. A CLI flag (-- --extract-and-run) — with a comment explaining why it’s needed.

Let me know if you'd like help verifying your Tauri version or updating the config!\n\n---\nthis is an automated review from Ollama

🤖 Automated PR Review:\n\n### 1) Summary This PR adds the environment variable `APPIMAGE_EXTRACT_AND_RUN=1` to the Linux AMD64 build step in `.gitea/workflows/auto-tag.yml`. The intent appears to be enabling AppImage runtime extraction mode (used by tools like `appimagetool` or `AppImageLauncher`) during the Tauri build process—likely to avoid sandboxing issues or ensure compatibility when the resulting AppImage is executed in certain CI or testing environments. However, **the change is likely incorrect or at least incomplete**, as `APPIMAGE_EXTRACT_AND_RUN` is **not a standard Tauri or Electron build-time environment variable**, and its placement in the workflow is ambiguous in terms of *when* and *for which process* it should take effect. --- ### 2) Bugs / Errors #### ❌ Misplaced or ineffective environment variable - `APPIMAGE_EXTRACT_AND_RUN` is **not a Tauri build flag**. According to [AppImage documentation](https://docs.appimage.org/reference/manifest.html#environment-variables), `APPIMAGE_EXTRACT_AND_RUN` is an *environment variable that must be set in the *runtime environment* of the AppImage itself* (e.g., by the user or system launching the AppImage), **not** during the build process. - Setting it at build time (as done here) has **no effect** on the generated AppImage — it only affects the *execution* of an *already-built* AppImage. - In fact, Tauri’s `tauri build` does **not** use or propagate this variable into the AppImage metadata or wrapper script. #### ⚠️ Potential confusion with `APPIMAGE_EXTRACT_AND_RUN` vs `APPIMAGE_EXTRACT_AND_RUN=1` - Even if the variable were used at runtime, the correct value is typically `APPIMAGE_EXTRACT_AND_RUN=1` (as used), but its *purpose* is to force extraction to a temporary directory and run from there — useful for read-only filesystems or sandboxed environments (e.g., Flatpak, some CI runners). - However, this is **not a build-time concern**, and setting it in the CI build step won’t make the AppImage *behave* this way automatically. #### 🛠️ Likely intended alternative: `TAURI_LINUX_APPIMAGE_EXTRACT_AND_RUN`? - Tauri *does* support a **build-time** config option: ```json "tauri": { "bundle": { "linux": { "appimage": { "extract-and-run": true } } } } ``` or via CLI flag: ```bash tauri build -- --extract-and-run ``` (Note: as of Tauri v1/v2, the flag may be named `--extract-and-run` or `--appimage-extract-and-run` depending on version.) 🔍 **Check Tauri version & docs**: - In Tauri v1.5+, the correct CLI flag is `--extract-and-run` for `tauri build`. - In Tauri v2, it’s part of the `appimage` bundle config (see [Tauri v2 docs](https://v2.tauri.app/reference/config/#linuxappimage)). ➡️ **Conclusion**: The PR likely *should* have added `--extract-and-run` to the `npx tauri build` command, not set an env var. --- ### 3) Security Issues #### 🔒 No direct security vulnerabilities - Setting `APPIMAGE_EXTRACT_AND_RUN=1` in CI is **low-risk** (it’s ignored), but: - If misused *at runtime*, `APPIMAGE_EXTRACT_AND_RUN` can increase attack surface (e.g., by extracting to world-writable `/tmp`), but this is irrelevant here since it’s set only during build. #### ⚠️ Indirect risk: Misconfiguration leads to broken AppImages - If the team *assumes* this env var fixes sandboxing issues in CI but it doesn’t, they may deploy broken AppImages to users or miss real fixes (e.g., missing AppArmor rules, incorrect permissions, or missing `--extract-and-run` in the actual bundle config). --- ### 4) Best Practices #### ✅ Correct placement & scope - Environment variables should be scoped to the *process that needs them*. - Here, `env:` is defined at the **step level**, which means it applies to the `run:` command (`npm ci`, `npx tauri build`). - But since `APPIMAGE_EXTRACT_AND_RUN` is not used by `npm`, `node`, or `tauri build`, it’s wasted. #### ✅ Prefer declarative config over env vars - AppImage behavior (like extract-and-run) should be configured in `tauri.conf.json` (v1) or `tauri.conf.json5` (v2), not via CI env vars. - This makes the behavior reproducible locally and documented. #### ✅ Use explicit CLI flags if needed - If CI must override config, use: ```yaml run: | npm ci --legacy-peer-deps CI=true npx tauri build --target x86_64-unknown-linux-gnu -- --extract-and-run ``` (Note the `--` to pass args to Tauri, not npm.) #### ✅ Document the intent - Add a comment explaining *why* this flag is needed (e.g., “Required for CI runners with restricted `/tmp`” or “Workaround for AppImage sandboxing in GitHub/Gitea Actions”). --- ### ✅ Suggested Fix Replace the `env:` block with the correct Tauri CLI flag and add a clarifying comment: ```diff - name: Build - env: - APPIMAGE_EXTRACT_AND_RUN: "1" + # Enable AppImage extraction-at-runtime to avoid sandbox issues in CI runners + # See: https://docs.appimage.org/reference/manifest.html#environment-variables run: | npm ci --legacy-peer-deps - CI=true npx tauri build --target x86_64-unknown-linux-gnu + CI=true npx tauri build --target x86_64-unknown-linux-gnu -- --extract-and-run ``` > 🔔 **Verify first**: Ensure your Tauri version supports `--extract-and-run`. For Tauri v1.5+, it does. For earlier versions, use the config file instead. Alternatively (and more robustly), configure it in `src-tauri/tauri.conf.json`: ```json { "tauri": { "bundle": { "linux": { "appimage": { "extract-and-run": true } } } } } ``` Then keep the CI step simple: ```yaml - name: Build run: | npm ci --legacy-peer-deps CI=true npx tauri build --target x86_64-unknown-linux-gnu ``` --- ### Final Recommendation **Reject this PR as-is.** - The change is ineffective and misleading. - Replace with either: 1. A config-based fix (`extract-and-run: true`), or 2. A CLI flag (`-- --extract-and-run`) — with a comment explaining why it’s needed. Let me know if you'd like help verifying your Tauri version or updating the config!\n\n---\n*this is an automated review from Ollama*

sarman merged commit eae1c6e8b7 into master

2026-04-13 02:16:45 +00:00

sarman referenced this issue from a commit

2026-04-13 02:16:47 +00:00

Merge pull request 'fix(ci): add APPIMAGE_EXTRACT_AND_RUN to build-linux-amd64' (#37) from fix/appimage-extract-and-run into master

Sign in to join this conversation.

No reviewers