New to fly.io. I’m unable to deploy my Go app using flyctl launch when following the Speedrun getting started. I cloned the example Go app and followed the instructions in the Docs using flyctl launch and encountered the same error.
Flyctl launch appears to run correctly until deploy. On deploy, builds using a remote builder. After a long wait (expected given Early look: "fly launch"), it errors with the following:
At quick glance it looks like buildpack builds are picking the target platform from your local machine instead of the docker daemon host. We’ll dig deeper and post an update.
Yep. Repeated command a few times on my Go app. First run set the remote builder up and downloaded the images for the buildpack. Second run image up to date, but exited with the same error. Then first run with example Go app, but seems to be using same remote builder, exited with same error.
I’m still running into a similar error, though at a different stage, using the builtin builder (I think?). Both are error during connect with an EOF.
Clone example Go app, fly init, blank name, select the Go builtin builder. fly deploy = image builds over 10 or so minutes, then on push = error during connect.
Did that error happen multiple times? It seems like the image built fine and there was an issue pushing to our registry. That’s a different failure mode than before.
We’re on. Tried again this evening: fly launch still exits, but fly init > fly deploy is successful. Updated flyctl from 0.0.190 > .195.
Re: multiple times - I think so, can’t recall if I tried multiple fly deploys or fly launches. Sorry!
If useful for troubleshooting buildpacks, the launch error remains invalid run-image but now connection reset by peer. Maybe remote builder timing out? I’m not wedded to this now that can use Dockerfile + remote build (cracking feature), although I love a buildpack!
All now ok, deleted remote-builder and fly launch works successfully with the hello-world. Sorry to waste your time!
I think the buildpack by default with fly launch only supports Go projects with a main.go in the root? For fly init/deploy, setting a more generic buildpack (eg. Heroku) solves this, or specifying targets via build flags.
Would the slick UX of fly launch be better with a more generic buildpack like Heroku 18? Because the docs/quick-start use fly launch having this fail quickly was a little disappointing. I am otherwise enjoying fly (that latency!).
Oh I’m glad you tried again! @jerome shipped a builder fix this morning, it probably fixed the bug you were hitting.
We are probably going to switch to Heroku buildpacks for everything. The paketo ones are ragged. I think most Go folks will want to do a Dockerfile at some point, but we really probably shouldn’t optimize for image size vs “not failing on first try”.
(I left a little gift on your billing page, thank you for bearing with us).
Well…I made good abuse of your remote builder! I’ve tried so many Dockerfile revisions over the last few days. Too spoilt by Buildpacks to remember to pass CGO_ENABLED=0 for a scratch build until this evening.
Hey thanks! That’ll lock me in . It’s an attractive service and wanted to persist, especially given your emphasis on latency. Might have a play with Postgres whilst trying to get litestream.io going.
I think that’s sensible. Works even if not optimal, versus image size but not work. Whilst troubleshooting I used a single-stage build and ended up at 1gb+. Still seemed to be handled with no difference to the 10mb multi-stage on deploy, even though feels gross. Once you’re onboard it’s much more tempting to optimise and either swap out your buildpack or move to a Dockerfile.
. It’s an attractive service and wanted to persist, especially given your emphasis on latency. Might have a play with Postgres whilst trying to get