My mistake on #32: I pinned the netbird-server image versions but didn't ship a deploy pipeline, so the change sat in git with nothing to apply it — and then I wrongly framed it as a manual SSH deploy. Every other Ansible-managed service has a path-triggered deploy-* pipeline that runs its play in the ci-ansible runner (which holds the SSH + vault creds); netbird-server just never had one.
This adds it, mirroring deploy-caddy.yml exactly:
push trigger on ansible/roles/netbird-server/**, ansible/plays/install-netbird-server.yml, and this file
Because the trigger includes its own path, merging this re-triggers the pipeline and deploys — applying the pinned 0.73.2 / v2.80.0 images on netbird.renner.uno.
⚠️ A management version bump runs a one-way store migration. If the live version is well behind 0.73, snapshot the VPS before merging. (If it's already ~0.73, this is effectively a no-op redeploy.)
After it deploys and reports ≥0.71, the IPv6-first follow-up is unblocked (enable IPv6 in Settings → Network, add the fd99::/64 route via netbird-ingress).
🤖 Generated with Claude Code
## Add the missing `deploy-netbird-server` pipeline
My mistake on #32: I pinned the `netbird-server` image versions but didn't ship a deploy pipeline, so the change sat in git with nothing to apply it — and then I wrongly framed it as a manual SSH deploy. Every other Ansible-managed service has a path-triggered `deploy-*` pipeline that runs its play in the `ci-ansible` runner (which holds the SSH + vault creds); `netbird-server` just never had one.
This adds it, mirroring `deploy-caddy.yml` exactly:
- **push** trigger on `ansible/roles/netbird-server/**`, `ansible/plays/install-netbird-server.yml`, and this file
- **manual** via `PIPELINE == deploy-netbird-server`
- runs `ansible-playbook -i inventory/ plays/install-netbird-server.yml -v`
Because the trigger includes its own path, **merging this re-triggers the pipeline and deploys** — applying the pinned `0.73.2` / `v2.80.0` images on `netbird.renner.uno`.
⚠️ A management version bump runs a **one-way store migration**. If the live version is well behind 0.73, snapshot the VPS before merging. (If it's already ~0.73, this is effectively a no-op redeploy.)
After it deploys and reports ≥0.71, the IPv6-first follow-up is unblocked (enable IPv6 in Settings → Network, add the `fd99::/64` route via `netbird-ingress`).
🤖 Generated with Claude Code
The netbird-server role had no deploy pipeline, so pinning its image
versions (#32) landed in git but never reached the VPS — there was
nothing to run install-netbird-server.yml. Every other Ansible-managed
service (caddy-ha, …) has a path-triggered deploy-* pipeline that runs
its play in the ci-ansible runner; netbird-server was simply missing one.
This mirrors deploy-caddy.yml exactly: push-triggered on the role, the
play, and this file; manual via PIPELINE==deploy-netbird-server. Merging
this re-triggers on its own path and runs install-netbird-server.yml,
applying the pinned 0.73.2 / v2.80.0 images on netbird.renner.uno.
Note: a management bump runs a one-way store migration — snapshot the
VPS before merging if the live version is well behind 0.73.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Add the missing
deploy-netbird-serverpipelineMy mistake on #32: I pinned the
netbird-serverimage versions but didn't ship a deploy pipeline, so the change sat in git with nothing to apply it — and then I wrongly framed it as a manual SSH deploy. Every other Ansible-managed service has a path-triggereddeploy-*pipeline that runs its play in theci-ansiblerunner (which holds the SSH + vault creds);netbird-serverjust never had one.This adds it, mirroring
deploy-caddy.ymlexactly:ansible/roles/netbird-server/**,ansible/plays/install-netbird-server.yml, and this filePIPELINE == deploy-netbird-serveransible-playbook -i inventory/ plays/install-netbird-server.yml -vBecause the trigger includes its own path, merging this re-triggers the pipeline and deploys — applying the pinned
0.73.2/v2.80.0images onnetbird.renner.uno.⚠️ A management version bump runs a one-way store migration. If the live version is well behind 0.73, snapshot the VPS before merging. (If it's already ~0.73, this is effectively a no-op redeploy.)
After it deploys and reports ≥0.71, the IPv6-first follow-up is unblocked (enable IPv6 in Settings → Network, add the
fd99::/64route vianetbird-ingress).🤖 Generated with Claude Code