To clarify my post: I see the reason for Firecracker to exist in general, it's great. But does "e2e tests" include untrusted code? I think it really shouldn't.
So why use firecracker here? Invoking your tests in a bare VM or container is great for making sure that you are controlling the environment and enumerating your system dependencies. But this post proposes discarding those things and instead using some saved state as the entry point into your Firecracker. So now you are booting from Your Image instead of a { Official Distro Image + Dependency Recipe }. It seems like a step backward.
Ah, then that's actually a pretty compelling use case. Not a "here's how you can do it" so much as a "here's how we did it (and kept you customers safe from the baddies)".
I think there's always been a push/pull of "fat base images" versus "install everything every time" - It's obviously subjective, but I think it's more important to run the tests on every commit than it is to start the environment from scratch.
It's also not necessarily mutually exclusive, you could have a "staging branch" where you make something that looks a lot like production and then re-run end-to-end tests there, while running the per-branch tests with this method to avoid slowing down developers.
Continuous integration can -- and does -- happen with local development teams using their own equipment. In general, those are typically pretty trusting environments where Firecracker style isolation is not as critical.
So why use firecracker here? Invoking your tests in a bare VM or container is great for making sure that you are controlling the environment and enumerating your system dependencies. But this post proposes discarding those things and instead using some saved state as the entry point into your Firecracker. So now you are booting from Your Image instead of a { Official Distro Image + Dependency Recipe }. It seems like a step backward.