Repository navigation
fix(scripts): install the pixi environment with --locked - #213
Conversation
With backend PR #48 committing a pixi.lock, provisioning and updates must actually honour it: plain 'pixi install' silently re-solves when the manifest and lock disagree (or when the unit's pixi cannot read the lock format), which defeats the reproducibility the lockfile exists to provide. --locked makes any mismatch fail loudly — in update.sh this happens before the running stack is touched, so a failed install leaves the old stack serving. Covers the provisioning half of NEH-106.
There was a problem hiding this comment.
Pull request overview
Enforces reproducible native backend dependency installation using the committed Pixi lockfile.
Changes:
- Adds
--lockedto fresh provisioning and field updates. - Preserves update failure before service shutdown.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
scripts/setup.sh |
Enforces locked Pixi installation during provisioning. |
scripts/update.sh |
Enforces locked Pixi installation before stopping services. |
| echo "→ Installing backend dependencies (pixi)..." | ||
| cd "$PROJECT_ROOT/backend" | ||
| run_as_user "$PIXI_BIN" install | ||
| run_as_user "$PIXI_BIN" install --locked |
There was a problem hiding this comment.
Right — the gitlink indirection is exactly what my landing-order note missed: a unit checks out the recorded SHA, not the branch tip. Fixed in b5016f0: this PR now advances the backend gitlink to a344b23 (which contains pixi.lock, backend #48 merged) in the same commit stream as the --locked change, so no superproject state demands a lock its pinned backend lacks.
| echo "→ Updating backend dependencies (pixi)..." | ||
| cd "$PROJECT_ROOT/backend" | ||
| run_as_user "$PIXI_BIN" install | ||
| run_as_user "$PIXI_BIN" install --locked |
There was a problem hiding this comment.
Addressed in b5016f0 — backend gitlink advanced to a344b23, which contains pixi.lock. --locked and the lockfile now land atomically.
Backend picks up #48 (pixi pins + committed pixi.lock) — bumped in the same PR as the --locked script change so no superproject state ever demands a lockfile its pinned backend does not contain. Also #47 (record_annotations) and #39 (renumber endpoint). Frontend picks up #28 (renumbering UI), #32 (annotations), #34 (NEH-126 shutter gating), #35 (aria-label i18n).
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (2)
scripts/setup.sh:91
backendis a pinned Git submodule, and this PR does not update its gitlink; the backend revision in this tree has nopixi.lock. Merging backend PR #48 alone does not change that pin, so fresh provisioning will always fail here with--locked. Update the backend submodule pointer to a commit containing the lockfile in this PR (or before enabling this line).
run_as_user "$PIXI_BIN" install --locked
scripts/update.sh:254
- The backend revision pinned by this superproject still has no
pixi.lock; merging the backend repository's PR does not advance this submodule gitlink. Consequently every field update from this tree aborts atpixi install --locked, even after backend #48 is merged. Pinbackendto the lockfile-containing commit as part of this change/release.
run_as_user "$PIXI_BIN" install --locked
Companion to backend #48 (merged), which commits a
pixi.lock. This is the provisioning half of NEH-106: both places that build the Pi's native backend environment —setup.sh(fresh provision) andupdate.sh(field update) — now runpixi install --locked, and the backend gitlink advances toa344b23(the post-#48devtip, which contains the lockfile) in the same PR — review pointed out, correctly, that merging #48 upstream alone is not enough, since units check out the superproject's recorded gitlink SHA, not the backend branch tip. The two changes landing together means no superproject state ever demands a lockfile its pinned backend does not contain.Why
--lockedmatters: plainpixi installsilently re-solves whenever the manifest and lock disagree, or when the unit's pixi treats a lock it cannot read as missing — so without it, the committed lockfile is advisory and two provisions can still resolve different builds. With--locked, any mismatch fails loudly; inupdate.shthat failure happens before the running stack is stopped, so a failed update leaves the old stack serving.Also rides along: the overdue frontend gitlink bump to
bc3aa80— #28 (renumbering UI), #32 (annotations), #34 (NEH-126 shutter gating), #35 (aria-label i18n).