ci: build the Linux Flatpak bundle in a Docker sandbox on Namespace runners

founder commented

2026-08-16 10:12:28 +00:00

Owner

build-linux.yml (job Build (Linux x86_64)) has failed on every run since 2026-05-25 (last green run 8910), when bc668f53 moved it from key-store-agent to namespace-profile-linux-large.

Root cause. The Namespace job container has no CAP_SYS_ADMIN and blocks unprivileged user namespaces; nsc run offers no privileged mode. So flatpak-builder's bwrap dies on the first module (bwrap: Creating new namespace failed: Operation not permitted) even with the setuid bubblewrap that prepare-flatpak-ci-sandbox.sh sets up (the process is already root — the container lacks the privilege). --disable-sandbox does not exist in flatpak-builder, so that fallback was a no-op.

Fix (per KSE-0173 §10/§15/§16, already proven green in the release Flatpak repo matrix, e.g. runs 17147/17114):

Scripts/build-flatpak-docker.sh — privileged debian:12-slim sandbox around Scripts/build-flatpak.sh (archive checkout, ensure-nix, ci-nix develop .#flatpak), copies the bundle back to Linux/App/build/. Mirrors build-flatpak-testing-repo-docker.sh.
Scripts/build-flatpak-ci.sh — CI entry: direct Bazel path when unshare -Ur works on the runner, Docker sandbox otherwise (KEYSTORE_FLATPAK_USE_DOCKER=auto|1|0).
build-linux.yml / build-flatpak.yml → namespace-profile-linux-amd64-large (enable_docker), call the CI entry, path triggers for the new scripts.
Docs: Linux/App/README.md, KSE-0173 §27.

The release lane's Build (Linux) (on key-store-agent-host) and Build (Flatpak Repo *) (Docker sandbox) are green and untouched.

Verification: workflow_dispatch of build-linux.yml on this branch (run id in the PR comments).

🤖 Generated with Claude Code

`build-linux.yml` (job `Build (Linux x86_64)`) has failed on every run since 2026-05-25 (last green run 8910), when bc668f53 moved it from `key-store-agent` to `namespace-profile-linux-large`. **Root cause.** The Namespace job container has no `CAP_SYS_ADMIN` and blocks unprivileged user namespaces; `nsc run` offers no privileged mode. So `flatpak-builder`'s `bwrap` dies on the first module (`bwrap: Creating new namespace failed: Operation not permitted`) even with the setuid bubblewrap that `prepare-flatpak-ci-sandbox.sh` sets up (the process is already root — the *container* lacks the privilege). `--disable-sandbox` does not exist in flatpak-builder, so that fallback was a no-op. **Fix (per KSE-0173 §10/§15/§16, already proven green in the release Flatpak repo matrix, e.g. runs 17147/17114):** - `Scripts/build-flatpak-docker.sh` — privileged `debian:12-slim` sandbox around `Scripts/build-flatpak.sh` (archive checkout, ensure-nix, `ci-nix develop .#flatpak`), copies the bundle back to `Linux/App/build/`. Mirrors `build-flatpak-testing-repo-docker.sh`. - `Scripts/build-flatpak-ci.sh` — CI entry: direct Bazel path when `unshare -Ur` works on the runner, Docker sandbox otherwise (`KEYSTORE_FLATPAK_USE_DOCKER=auto|1|0`). - `build-linux.yml` / `build-flatpak.yml` → `namespace-profile-linux-amd64-large` (`enable_docker`), call the CI entry, path triggers for the new scripts. - Docs: `Linux/App/README.md`, KSE-0173 §27. The release lane's `Build (Linux)` (on `key-store-agent-host`) and `Build (Flatpak Repo *)` (Docker sandbox) are green and untouched. Verification: workflow_dispatch of `build-linux.yml` on this branch (run id in the PR comments). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

founder added 1 commit

2026-08-16 10:12:28 +00:00

ci: build the Linux Flatpak bundle in a Docker sandbox on Namespace runners

Build: Linux / Build (Linux x86_64) (pull_request) Successful in 20m28s

Details

Build: Linux / Build (keystore-forge x86_64) (pull_request) Has been skipped

Details

44e9ecb93e

build-linux.yml has failed on every run since 2026-05-25, when bc668f53 moved
it from key-store-agent to namespace-profile-linux-large. That Namespace job
container has no CAP_SYS_ADMIN and blocks unprivileged user namespaces, and
`nsc run` has no privileged mode, so flatpak-builder's bwrap dies on the first
module (`bwrap: Creating new namespace failed: Operation not permitted`) even
with the setuid bubblewrap fallback that prepare-flatpak-ci-sandbox.sh sets up.

The release Flatpak repo matrix already solved this per KSE-0173 §10/§15/§16:
run on the Docker-enabled namespace-profile-linux-amd64-large target
(nsc --enable_docker) and build inside a privileged Docker container. Do the
same for the plain bundle lanes:

- Scripts/build-flatpak-docker.sh: privileged debian:12-slim sandbox around
  Scripts/build-flatpak.sh (archive checkout, ensure-nix, ci-nix develop
  .#flatpak), copying the bundle back to Linux/App/build/. Mirrors
  build-flatpak-testing-repo-docker.sh.
- Scripts/build-flatpak-ci.sh: CI entry that keeps the direct Bazel path when
  `unshare -Ur` works on the runner and otherwise uses the Docker sandbox
  (KEYSTORE_FLATPAK_USE_DOCKER=auto|1|0).
- build-linux.yml / build-flatpak.yml: switch to
  namespace-profile-linux-amd64-large and call the CI entry; add the scripts to
  the path triggers.
- Document the runner constraint in Linux/App/README.md and KSE-0173 (§27).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

founder requested reviews from cdo, forge, runner, release-runner, assistant, security-agent, windows, cmo, manager, ios, linux, web, infra, devex, agent, billing, android

2026-08-16 10:12:28 +00:00

founder commented

2026-08-16 10:35:15 +00:00

Author

Owner

Verification: workflow_dispatch of build-linux.yml on this branch → run 17184 (UI index 17150, https://git.key.store/key-store/key.store/actions/runs/17150) is green on namespace-profile-linux-amd64-large: Building Flatpak bundle in a Namespace Docker sandbox → all modules built → Flatpak bundle written to /workspace/Linux/App/build/store.key.application.flatpak → Docker-backed Flatpak bundle copied to …/Linux/App/build/store.key.application.flatpak → Job succeeded (10:18–10:33 UTC).

Note for the record: the first attempt of the PR-triggered run (17183) was cut off at 10:17 because Forgejo handed it to a daemon-mode runner (nscloud-176cbcc386d5, launched 08:47 for the release lane) two minutes before that instance's 90-minute nsc run --duration expired; Forgejo re-queued the job. That is a pre-existing forgejo-nsc lifecycle issue (together with ~70% of Namespace launches being destroyed within seconds by the dispatcher's first stop-check), tracked separately.

Verification: `workflow_dispatch` of `build-linux.yml` on this branch → run **17184** (UI index 17150, https://git.key.store/key-store/key.store/actions/runs/17150) is **green** on `namespace-profile-linux-amd64-large`: `Building Flatpak bundle in a Namespace Docker sandbox` → all modules built → `Flatpak bundle written to /workspace/Linux/App/build/store.key.application.flatpak` → `Docker-backed Flatpak bundle copied to …/Linux/App/build/store.key.application.flatpak` → `Job succeeded` (10:18–10:33 UTC). Note for the record: the first attempt of the PR-triggered run (17183) was cut off at 10:17 because Forgejo handed it to a daemon-mode runner (`nscloud-176cbcc386d5`, launched 08:47 for the release lane) two minutes before that instance's 90-minute `nsc run --duration` expired; Forgejo re-queued the job. That is a pre-existing forgejo-nsc lifecycle issue (together with ~70% of Namespace launches being destroyed within seconds by the dispatcher's first stop-check), tracked separately.

founder force-pushed claude/epic-hellman-ad90c4 from 44e9ecb93e

Build: Linux / Build (Linux x86_64) (pull_request) Successful in 20m28s

Details

Build: Linux / Build (keystore-forge x86_64) (pull_request) Has been skipped

Details

to 84d37aeacf

Deploy: API / Deploy (API) (push) Has been cancelled

Details

Release: If Needed / Check (Release Needed) (push) Has been cancelled

Details

Deploy: Web / Deploy (Web) (push) Has been cancelled

Details