Frustrating user-error `flyctl deploy -app=${APP}`

This is user-error but perhaps:

  1. A more descriptive error message?
  2. Is there a way to query an org’s/app’s container registry?
flyctl deploy -app=foo
==> Verifying app config
--> Verified app config
==> Building image
Searching for image 'registry.fly.io/{app}:{tag}' remotely...
Error failed to fetch an image or build from source: Could not resolve 

After much head-scratching and comparing a script that works with one that does not, I realized the issue is the difference between a single and double-hyphen on the --app flag.

And so, of course:

flyctl deploy -ap
==> Verifying app config
--> Verified app config
==> Building image
Searching for image 'registry.fly.io/{app}:{tag}' remotely...
Error failed to fetch an image or build from source: Could not resolve 

This is user-error because with Unix short flags can be combined but IIUC there is no -p flag for flyctl deploy so, should flyctl deploy -ap not be rejected as an error?

My issue may (!?) be compounded by the absence of an app property in the fly.toml.

I wondered whether there were push latency on the image, whether I had mistyped the image tags etc.

I was unable (is there a way?) to query the org’s/app’s registry for the image to confirm whether it was successfully pushed|present. That would have helped me.

--verbose doesn’t help.

Unfortunately the error messages are generally quite vague. Lots of “unknown error” type ones. Hopefully Fly will improve those with time.

You are right that with flags, generally a single hyphen is for short ones e.g -h whereas the longer double-hyphen is for e.g --help. So with Fly, that would be -a or --app (either are fine). As you’ve found. And that’s not needed at all if you have a fly.toml with an app = "name" line.

As regards a list of images, I know you can get deployed ones, if that’s all you need …

fly releases --app name --image

Not sure if you can get non-deployed ones some other way (build-only).

Thanks @greg

With the flags, my issue was more that, inadvertently mistyping -app (which is equivalent to -a -p -p) should fail because there is no -p flag and unfortunately, is an easy (!?) mistype of --app.

Thank you for the pointer to release --app=${APP} --image – that’s exactly what I sought.

1 Like

this is a really good point, and thank you for taking the time to highlight this surprising behavior. Definitely something to think about, and I’ll make sure that it gets to the right people on our team. If you’d like, you can always also create an issue on the flyctl repo!

1 Like

@eli thanks for the feedback!

I did start at the GitHub repo (new issue) but, because this wasn’t a bug report (per se), I chose the other listed path of using this Community Forum.

1 Like