Make the time-to-deploy 2x quicker: 2mins vs 4mins

[gerhard]

First run, empty cache (first time penalty)

Second run, primed cache

---

This replaces our Dagger on Fly.io setup with Dagger on Namespace.so

We still keep K8s to see if we can improve on Namespace.so, the new Speed King 🏎️

This is the first part of the required change. The second part will follow after this gets merged. We need to:

• Cleanup secrets & variables from GitHub Actions
• De-provision the Dagger Engine on Fly.io
• Remove the deploy config from fly.io dir
• Update the INFRASTRUCTURE diagram

---

Before this change, throughout August 2024:

• deploys took 4m 36s 95% of the time
• 1 in 14 deploys failed, meaning we had a 93% success rate

[gerhard]

On the second run, I was expecting Build, test & publish... to use the cached Docker volume /cache/dagger-0-6-4: https://github.com/thechangelog/changelog.com/actions/runs/10664539072/job/29556003383

This is how the same run behaved on K8s, where the cache was definitely used: https://github.com/thechangelog/changelog.com/actions/runs/10664539072/job/29556002949

I was expecting that particular step to take around 40s on Namespace, but it took 2m 56s. I have confirmed that none of the operations were cached.

Why did the cached volume not work as expected on Namespace.so? This message might explain it, even if it's somewhat hidden:

If cache misses are indeed "very rare", I would expect the next run to have a cache hit. Let's see...

[gerhard]

That was it!

Second run worked much better: 20s for the Build, test & publish... step: https://github.com/thechangelog/changelog.com/actions/runs/10664539072/job/29556746670

This now looks right too:

It will be worth keeping an eye on these cache misses over the next few weeks (notice the time difference between the first 2 uncached runs vs the third cached run):