I would be really very surprised if my caching changes really caused this: I made them after realizing that we were almost always evicting caches before even using them once.

Then again, this is caching. It is CI. It is a combination caching and CI. So who knows!

@tschneidereit I am also surprised. And yet after weeks of Ubuntu testing needing multiple re-runs, I made this change and it completed first time. It could be that using cache disguises some sort of unrelated issue, and the true fix is for that unrelated issue? (Like you say: CI, who knows.) And of it could be that this is not a fix and I just had a freakish run of good luck with these two PRs! I dunno. I just want to not have to do repeated re-run cycles on every push.

My suggestion is that unless we either:

1. Know a compelling reason not to re-enable cache in this one context; or
2. Have another avenue we'd like to explore

then we take this PR and at least see if it helps.

One thing maybe worth doing is to delete the cache entry and retrigger the run. If that also succeeds, I think it's pretty unlikely to be a fluke, and we should definitely land this.

I would in general say land it, except I find it so utterly baffling that the act of storing a cache entry would make something pass that didn't before. And looking at the log, as I'd expect there's no cache hit, so the only functional difference here really seems to be that after everything has run, the cache entry is created.

Ooh, except that's not the case, as I realize now, right after sending the previous comment!

At the very least, the cache action also sets CARGO_INCREMENTAL=0, but it might make different changes as well. That's the right thing to do in CI regardless of whether we cache or not, and certainly is a meaningful change in build config.

Oho! Good find. I've just kicked off the re-run after deleting the cache. Then I can try it without cache but with CARGO_INCREMENTAL=0. Thanks!

ETA: #3298

CARGO_INCREMENTAL=0 but no cache failed (https://github.com/spinframework/spin/actions/runs/18387466027).

I understand that this shouldn't work but it tentatively seems like it does. Could we merge it for now in the hope that it helps, even if incorrectly? And then we can do more research on a thing that is more correct when we are not having every PR require multiple re-runs?

Well, my hope was misplaced: https://github.com/spinframework/spin/actions/runs/18451759414/job/52566336947?pr=3290

I shall settle for replacing it with a hope that at least things will be slightly less worse.

Anyone got any further ideas?