Sometimes the WireGuard gateway - specifically fdaa:0:4556::3 - is failing to respond to pings. This is problematic since our GitHub Actions runner is unable to establish connectivity to our Dagger Engine running on Fly.io: FWIW Run Dagger Engine as a Fly Machine (no more Docker) by gerhard · Pull Request #471 · thechangelog/changelog.com · GitHub
Since we introduced a fallback mechanism (Make our ship_it.yml GHA workflow resilient by gerhard · Pull Request #476 · thechangelog/changelog.com · GitHub), this is less of a problem, but I would appreciate double-checking that:
- we are not doing something obviously wrong
- we understand why this is failing
- there is a path to improving it
You can see the latest failure in this job run (I expect these logs to be pruned within the next 30 days): Fix `1st argument: not a bitstring` error · thechangelog/changelog.com@306769e · GitHub
For posterity, here is a point-in-time screenshot:
On a fresh GitHub Actions runner, we perform the following steps sequentially:
Install WireGuard & friends…
Configure WireGuard tunnel…
Check IPv6 routes…- Check DNS resolution…
Can we ping fdaa:0:4556::3?- Can we resolve
dagger-engine-2023-05-20.internalviafdaa:0:4556::3? - Can we ping
fdaa:0:4556:a7b:15f:b690:cc49:2? - Can we connect to Dagger running on
fdaa:0:4556:a7b:15f:b690:cc49:2? 
Run on tcp://[fdaa:0:4556:a7b:15f:b690:cc49:2]:8080…
This is what a successful run looks like: Run Dagger Engine as a Fly Machine (no more Docker) (#471) · thechangelog/changelog.com@60664a2 · GitHub
And this is a failing run (same config for both runs): Fix `1st argument: not a bitstring` error · thechangelog/changelog.com@306769e · GitHub
How can we improve this?