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.
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.
