Some checks failed
Build and publish packages / build-and-publish (push) Failing after 14m14s
The act_runner exports CARGO_TARGET_DIR=/cache/target for cache
persistence, but the three Rust-app PKGBUILDs hardcoded
target/release/<bin>. Run 87 compiled 8 min then failed at
install stage. Use ${CARGO_TARGET_DIR:-target} so both CI and
local makepkg work.
6.6 KiB
6.6 KiB
Decisions
2026-04-23 – Rust PKGBUILDs honour CARGO_TARGET_DIR
- Who: Dominik, ClaudeCode
- Why: The act_runner container sets
CARGO_TARGET_DIR=/cache/target(for cross-build cache persistence), butmoongreet-git/moonlock-git/moonset-gitpackage()hardcodedtarget/release/<bin>. Run 87 compiled for 8 min and then failed atinstall: cannot stat 'target/release/moongreet'because the binary actually lived in/cache/target/release/. Silent until today because earlier builds pre-date the env var. - Tradeoffs: None meaningful — the fallback
${CARGO_TARGET_DIR:-target}preserves localmakepkgbuilds (no env var → still reads from./target/). - How: Patched
install -Dm755in all three Rust-app PKGBUILDs to use"${CARGO_TARGET_DIR:-target}/release/<bin>".
2026-04-23 – Single-threaded, low-priority build in CI to keep the Gitea host alive
- Who: Dominik, ClaudeCode
- Why: The act_runner container shares CPU/RAM/I/O with the Gitea host (network-host mode, no resource limits). Parallel Rust builds OOM-kill or thrash the host: run 86 (2026-04-23, moongreet-git 0.8.3.r1) stopped mid-compile at
Compiling gio v0.22.2with no error, and gitea HTTPS was unreachable for ~11 min. Same pattern on 2026-04-20. Runner-side resource limits would be better, but require host-side config changes; a pipeline-side fix is portable and low-risk. - Tradeoffs: Builds are slower — single-threaded cargo compile of a moon* project takes ~2–3× as long.
nice -n 19+ionice -c 3further delay the build when the host is busy, but that's the point. Slow build beats downed host. - How:
build-and-publish.yamlexportsCARGO_BUILD_JOBS=1andMAKEFLAGS=-j1beforemakepkg, and wrapsmakepkgwithnice -n 19 ionice -c 3. Affects every package build in the matrix.
2026-04-21 – moonarch-git becomes a full meta-package (hard deps on all Arch-repo essentials + own registry siblings)
- Who: Dominik, ClaudeCode
- Why:
moonarch-gitlistedmoongreet-git/moonlock-git/moonset-gitonly asoptdependsand omitted most Arch-repo essentials (wlsunset, networkmanager, bluez, xwayland-satellite, file-manager stack, zsh plugins, CLI tools, …) entirely — they lived only inpackages/official.txt.paru -S moonarch-giton a fresh system therefore produced a desktop with no greeter, no lockscreen, no power menu, no nightlight, no network manager, no portals — a non-functional Moonarch. Split source of truth between PKGBUILD deps and txt files caused continuous drift (e.g. walker-bin was missing from both). - Tradeoffs:
moonarch-gitis now chunky — installing it pulls ~60 packages (vs ~20 before). Acceptable because this is exactly what every Moonarch system needs; a leaner package just shifted the install work to imperative scripts that silently failed. AUR packages cannot be harddepends=(pacman can't resolve AUR), so they stay inpackages/aur.txtand post-install.sh pulls them explicitly.optdepends=was slashed to real extras (docker, rustup for dev, waterfox) — no more mirroring of aur.txt there. - How: Added to
depends=: moongreet-git, moonlock-git, moonset-git, xwayland-satellite, libnotify, foot-terminfo, wlsunset, nwg-look, awww, libpulse, gst-plugin-pipewire, networkmanager + nm-applet + nm-openvpn + openvpn, bluez, gvfs + gvfs-{dnssd,mtp,smb}, udisks2, ntfs-3g, xdg-desktop-portal-{gnome,gtk}, qt6-5compat, zsh-{autosuggestions,syntax-highlighting}, bat, btop, eza, fastfetch, fd, fzf, lazygit, ripgrep, neovim, git, fwupd, ufw. Removed fromoptdepends=: all Moonarch ecosystem packages (now hard deps), all AUR packages (post-install.sh pulls from aur.txt), and already-depended Arch-repo packages.pkgrelbumped 9 → 10.
2026-04-20 – Registry is the only install path; drop paru --pkgbuilds
- Who: Dominik, ClaudeCode
- Why: Two parallel mechanisms for finding moonarch packages (the Arch registry via
[moonarch]inpacman.conf, and paru's PKGBUILD-repo via[moonarch-pkgbuilds]inparu.conf) created ambiguous state:paru -Sresolves from whichever has a matching version first, and diagnostics have to account for both. With the registry DB now stable (see zombie fix below), the PKGBUILD-repo path is redundant. - Tradeoffs: No more local-build fallback when the registry is broken — but when the registry is broken, the real fix is to repair it, not to mask the problem with a second mechanism. Existing systems need their
/etc/paru.confcleaned once (hook handles that on next moonarch-git upgrade). - How:
moonarch.installpost_install now deletesMode = arpand the[moonarch-pkgbuilds]section from/etc/paru.confinstead of writing them.moonarch/scripts/post-install.shandtransform.shno longer configure paru.conf or callparu -Syu --pkgbuilds; they runpacman -Sy+paru -S moonarch-git(registry only).
2026-04-20 – CI wipes all package versions before upload to kill DB zombies
- Who: Dominik, ClaudeCode
- Why:
paru -Syustopped offeringmoonarch-gitupdates after the r99 → r105 pkgver bump. Root cause: Gitea's Arch registry updatesmoonarch.dbincrementally on upload, but does not evict old entries when a pkgver changes.r99lingered in the DB as a zombie — file already 404, but desc/sig still present — so clients sawr99as "latest" and never gotr105. Not a one-off: every future pkgver bump would repeat the issue. - Tradeoffs: Delete-before-upload adds an HTTP round-trip per package and requires
read:packageon the registry token (write:packagewas already there for upload). Alternative was an admin-side DB scrub per zombie — unscalable and hostile to the user. - How:
build-and-publish.yamlnow lists every existing version of each built package viaGET /api/v1/packages/{owner}?type=arch&q={name}andDELETEs them before the upload loop. jq installed on the runner as a dependency of the listing parser. The per-uploadDELETEof the exact new version was removed (redundant).
2026-04-20 – Register moongreet/moonset/sweet-cursors in the Arch registry
- Who: Dominik, ClaudeCode
- Why: These three packages were missing entirely from the registry — their last pkgver-bumps landed before the
build-and-publishCI fixes (makedepends install, source-based PKGBUILD parse, multi-artifact upload). Without a new PKGBUILD change, the workflow never re-triggered, so they stayed absent. - Tradeoffs: Bumping
pkgrelmanually is a one-shot push. Alternative (wait for the next real upstream change) would have left packages uninstallable indefinitely. - How: Bumped
pkgrelin each PKGBUILD, single commit, triggered thebuild-and-publishworkflow.