serokell
Magic rollback activation test should have option to reboot as part of the test
In cases where, for instance, you're installing a new kernel or network driver, it's easy for some driver complication to soft brick the device by preventing network connections on reboot. So you can have the device pass the test, reboot, and then suddenly no longer be accessible.
To prevent cases like this, it would be useful to have an option to have magic rollback reboot the device first, as part of the test, then have its instance on the remote device revert changes and reboot again, in the event that contact can no longer be made with the deploying device.
I was about to say #176 implements this, but it doesn't support magic rollback 😔
This would be somewhat tricky to get right without extreme specialization. Technically deploy-rs is just a Nix profile deployment tool, and only a NixOS deployment tool as an extension of that.
The current magic-rollback system (which by the way, is kindof awful tbh) works by double forking a wait process, which will re-activate the old generation if it is not confirmed, which of course works on profiles of any type.
Although, the bootstuff stretches how generic deploy-rs is a little bit, so...
Maybe how it could work, is activators can advertise that they automatically launch the "wait" on boot, then inside of your NixOS configuration (though we could offer a helper maybe?) it is configured to always launch it if a canary file exists (or whatever we replace that dodgy system with), and whenever both "magic-rollback" and "boot" are used at the same time, it should allow it if (and only if) your activator supports this, and behavior-wise simply skips launching the double-forked "wait" process. I think that would potentially work.
(my reasoning behind this specific idea is it should work well and make sense with home-manager and some other profiles)
