azure-gate: fix bicep deploy on the NixOS runner (PATH bicep) #151

Merged

trevato merged 1 commit from fix/azure-gate-bicep-nixos into main

2026-08-19 20:00:05 +00:00

trevato commented

2026-08-19 19:58:28 +00:00

Owner

Next failure after the clone/pager fixes — and the reason the last run failed in ~7s. Pulled the actual error from Forgejo's action-log storage:

The configuration value of bicep.use_binary_from_path has been set to 'false'.
Could not start dynamically linked executable: .../.azure/bin/bicep
NixOS cannot run dynamically linked executables intended for generic linux environments

az deployment group create -f main.bicep auto-downloads a generic-linux bicep ELF into ~/.azure/bin, and the vxrail runner is NixOS, which can't exec it. The run got all the way through clone → SP login → RG create → deploy before dying here (and it tore down cleanly — no leak), so the earlier fixes are confirmed working.

Fix: add nixpkgs#bicep to the workflow's nix shell, and in gate.sh set az config set bicep.use_binary_from_path=true whenever bicep is on PATH. So CI uses the nix bicep; a laptop with no bicep on PATH keeps using az's own download (which works fine off-NixOS). Laptop == CI preserved.

This should be the last blocker for a green vms run.

🤖 Generated with Claude Code

Next failure after the clone/pager fixes — and the reason the last run failed in ~7s. Pulled the actual error from Forgejo's action-log storage: ``` The configuration value of bicep.use_binary_from_path has been set to 'false'. Could not start dynamically linked executable: .../.azure/bin/bicep NixOS cannot run dynamically linked executables intended for generic linux environments ``` `az deployment group create -f main.bicep` auto-downloads a generic-linux `bicep` ELF into `~/.azure/bin`, and the **vxrail runner is NixOS**, which can't exec it. The run got all the way through clone → SP login → RG create → deploy before dying here (and it tore down cleanly — no leak), so the earlier fixes are confirmed working. **Fix:** add `nixpkgs#bicep` to the workflow's `nix shell`, and in `gate.sh` set `az config set bicep.use_binary_from_path=true` whenever `bicep` is on PATH. So CI uses the nix bicep; a laptop with no bicep on PATH keeps using az's own download (which works fine off-NixOS). Laptop == CI preserved. This should be the last blocker for a green vms run. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

trevato added 1 commit

2026-08-19 19:58:28 +00:00

azure-gate: fix bicep deploy on the NixOS runner (use PATH bicep, not az's download)

guard-ppt / no-ppt (push) Successful in 19s

Details

guard-ppt / no-ppt (pull_request) Successful in 20s

Details

5764480a67

The real deploy failure: az deployment auto-downloads a generic dynamically
linked bicep ELF into ~/.azure/bin, which NixOS (the vxrail runner) cannot
exec ('Could not start dynamically linked executable'). Add nixpkgs#bicep to
the workflow's nix shell and, in gate.sh, point az at the PATH bicep
(az config set bicep.use_binary_from_path=true) whenever bicep is present —
so CI uses the nix bicep and a laptop (no bicep on PATH) keeps using az's own.
Clone + pager fixes confirmed working; this was the next failure in line.

trevato merged commit 55ec5e64c0 into main

2026-08-19 20:00:05 +00:00

trevato referenced this pull request from a commit

2026-08-19 20:00:07 +00:00

azure-gate: fix bicep deploy on the NixOS runner (PATH bicep) (#151)