… and I’m not quite sure how to troubleshoot, given just how little has been done. The problem has occurred in multiple regions.
For what it’s worth, my immediate end-goal is deploying an Elixir application without phoenix; I was just running into this docker issue, and tried for the minimum reproducible example.
Do you have a docker engine running locally? You could circumvent it by adding the --remote-only. Meanwhile, I would like to know what happened. Can you paste the output of LOG_LEVEL=debug flyctl deploy here?
So, I left the house immediately after I made this post, and, fortunately for me, and unfortunately for anyone else who has a similar problem in the future, this appears to have been a hiccup. When I ran LOG_LEVEL=debug flyctl deploy several hours later, I got deployed successfully back just fine.
Edit: For future reference, if this comes up again, I wasn’t running docker locally. ¯\_(ツ)_/¯
Glad to hear you managed to get over it. There are still a few issues that sometimes spoil the remote builders’ experience but we are working to smooth everything out. Here is what we have done so far: WireGuard and Remote Builder Fixes in flyctl
For posterity’s sake, I am almost certain (as in, I can reproduce this behavior if build, intentionally roll my local machine’s system clock back, and then attempt to build again) that this was a time problem: that a misconfiguration between two local machines caused a build to claim to the builder that it was older than the current deployment; I don’t know what threw up its hands down the line from there—Firecracker, Docker, something specific to fly.io—but to whatever extent closing the circle helps you folks!
Thanks for the update. I was able to reproduce this as well. flyctl connects to your remote builder over WireGuard which requires system clocks to be in sync. We’ll do more testing and see if this is a widespread issue.