A workaround seems to be to give the machine metadata fly_platform_version=v2 (e.g. flyctl machine update 5683dde2a70778 --metadata fly_platform_version=v2) and then running flyctl deploy.
To do that as a single-shot, apparently flyctl deploy --force-machines works. Hooray! (And if you use scheduled machines, set the schedule after deploy with flyctl machines update XXX --schedule hourly.)
thanks for the bug reports! flyctl config env -a machine-env-is-broken certainly shouldn’t crash like that, and machines should probably be able to inherit the environment from the config file. I’m working on a fix to both for these.
I’m glad you were able to find a solution!
Word of warning: as you probably know, giving a machine that metadata means that it’s managed as part of the Apps V2 platform, which means that certain kinds of changes you may make to it are liable to be reverted on deploy. I don’t think that schedules should end up getting wiped, but it’s something to watch out for!
How did you set the secrets? I’m not able to reproduce this one.
Actually, it turns out that you can’t get flyctl deploy and --schedule hourly to cooperate. A flyctl machine update XXX --schedule hourly wipes out the configuration with empty environment again (status gives a new instance ID, history is truncated), and a new flyctl deploy will forget the schedule part.
Also, flyctl machine update times out more often than it completes successfully, and re-running the same command says the config change has already been done.
I need to do other things again for a while, but when I come back to this (if flyctl hasn’t improved in the meanwhile), I guess I’ll look at using the API directly.