`fly deploy --app <name>` in a folder with a fly.toml

The screenshot says it all, but in the latest version of the fly CLI, it appears that the --app flag is ignored in cases where fly.toml exists in the directory and the app name doesn’t match.

This is a pretty bad bug (if we’re interpreting it correctly – see the screenshot, which shows this behavior). In this instance, it caused a deploy to staging to instead deploy to production. We can change the behavior in our codebase to work the other way around, but this is the kind of bug that we’d not expect to see, that erodes trust in the process of always using the up-to-date Fly CLI.


Yep. Broke our production deployment - pushed staging to prod.

EDIT: I should probably note. This is a super severe bug.

We use Github Actions to deploy. Despite the fact we pin all our Github Actions in order to try mitigate exactly this kind of issue - the Fly.io GH Action is poorly designed and downloads the latest CLI.

We simply committed and pushed as per usual without any modification to fly.toml, any explicit CLI upgrades, or any changes to our Github Actions. Our Github Actions ran and passed tests, so deployed to staging - or at least - tried to.

The deployment didn’t flat-out break production, so uptime monitoring reported no issues. Instead when users attempted to perform a core action it failed due to database migrations not being applied. Github Actions applied them to our staging environment only - as it should have.

There’s a 99% chance we’re migrating away from Fly.io as a result of this. Well, this isn’t the only issue we’ve encountered, but it’s certainly the most severe. I’ve only been using Fly.io for a few months, and the issues have been non-stop. The premise is great - execution - not so much.

1 Like

Sorry about this folks. We’ve made a few big changes that did not get caught be automated tests. The good news is that it’s an easy fix, so I’ll update here when it’s out.

1 Like

v0.0.424, which fixes this issue, should be out shortly. One thing to note - you can pin the flyctl version in Github actions like this:

- uses: superfly/flyctl-actions/setup-flyctl@master
    version: 0.0.424

UPDATE: v0.0.424 with this fix was just released.

1 Like

This has been broken for machines since long. I fixed it in this commit (which I’m using in my flyctl fork to keep the CI going…): Improvements to deploy and run commands for machines by ignoramous · Pull Request #1327 · superfly/flyctl · GitHub any chances it gets pulled in? If so, I’ll rebase and resubmit.

@ignoramous This should be fixed now for machines. I’ll comment on the PR for the rest.