When I was working on my first fly app, I got a lot of help from the good folks at fly getting my dockerfile and github action wired up. Now I’m trying to understand why using docker/setup-buildx-action, actions/cache, docker/login-action, and docker/build-push-action to finally just run fly deploy --image is so useful:
I routinely point to folks to your repo’s GitHub Actions (ex) as an example of how they can build and push to Fly registry themselves, when flyctl deploy ... isn’t cutting it for them (:
Hmmm… Those look like edge cases. And I think using --remote-only will have a better (managed) caching trade-off in a GitHub actions scenario as well thanks to the free builders offered by fly.
I guess I’m switching all my stuff to the simpler config.
Remote builds are probably fine from GitHub these days. They’re more intricate though. flyctl connects to remote builders over WireGuard. GitHub actions need to create a new WireGuard peer in our stack for every run, wait for it to be provisioned, then start their build.
This is reasonably fast and reliable these days, but we had issues scaling WireGuard peers for several months last year. Build + push + fly deploy -i was much more reliable back then.
One thing splitting them up does add is potential parallelism. You can build an image while tests are running then wait to deploy. You may be able to do the same with flyctl natively: