[Web] Don't cache emsdk

[AThousandShips]

Due to how caching works between branches, and this cache being identical for the same version, having this cached doesn't really help. Unfortunately unifying these cache entries doesn't work because of this, so I think it's better to just not cache them at all, downloading emsdk doesn't seem to take much time either (especially since I think CI caches downloads in other ways already) so this won't really hurt performance wise

But saves us a sizable amount of cache space

I've made a 3.x specific version as well and will open a PR for that if this is approved

[AThousandShips]

The alternative solution would be to simply not cache emsdk at all, I don't think that would cost all that much in the runtime of the checks, but I'd say we should either unify the cache entries or not cache at all

[AThousandShips]

Doing some further reading on cache management it seems this cache cannot be read by other branches when created on a branch, so will change this to simply not caching emsdk as it isn't functional and do some further testing

[akien-mga]

Just to clarify the intent of the cache, the original idea was to try to cache only based on the Emscripten version, so all builds that use the same Emscripten version would just reuse that cache. So we'd have at most one cache per Emscripten version (and maybe per Godot base branch?).

But I never really understood in depth how the cache key system works and I'm not sure it ever worked. What did cause issues however was that the Emscripten GH action didn't seem able to cope with two jobs trying to access the same cache at the same time. Or maybe it was upload - where I'd question why we're always reuploading a new version to the cache, ideally it should be treated as static and only require an upload if the data needs to change.

So if we can't make it work like that, removing the cache makes sense to me.

---

Note that another thing which should (at least I would expect it to) get cached is generated during the build, as you can see at the end of the Compile step:

cache:INFO: generating system asset: symbol_lists/532cf52649ea564c884d63e646c170c4e1bc83d0.json... (this will be cached in "/home/runner/work/_temp/cb745811-a123-4446-b3b0-d22635069551/emsdk-main/upstream/emscripten/cache/symbol_lists/532cf52649ea564c884d63e646c170c4e1bc83d0.json" for subsequent builds)
cache:INFO:  - ok

But this may not take too long to generate so it's probably an ok tradeoff to not do caching for emsdk on CI.

When doing LTO builds, there's a lot more stuff that gets generated at linking time and that can be cached, but that's not a use case we have on CI.

[AThousandShips]

So to clarify some details:

• The current cache key would need to be changed regardless as it would only match the exact same SHA
• A cache can only be loaded by either:
  • The branch that created it
  • A merge in a PR that is based on that same branch (i.e. a PR starting from master could access it if created on master, but master could not fetch it from the PR, nor another PR fetch it from that PR)

So to fix this we'd have to create this cache only on individual branches, like master or 3.x and then only fetch in PRs

This could work, not sure exactly how to do CI foo to achieve that but it's possible, it would only update the cache when ever it fails to fetch one, but we'd need to do something to ensure the cache is generated before we run the two web builds or they'd clash.

We could theoretically do this as part of the static checks, but I think such a change, being bound to a specific branch, would be pretty fragile

For the last step of the compilation that doesn't seem to be cached between runs and will look into if we can do so separately, it isn't stored in the emsdk cache path provided by the action so it seems to be separate, but will investigate

---

To put the cache load of the emsdk cache into perspective we currently have ten entries for emsdk in our caches, totaling around 4.2 GB just from 4.x, and for 3.x just one but 710 MB, so around half of our cache allotment is taken up just by that currently

[Repiteo]

To put the cache load of the emsdk cache into perspective we currently have ten entries for emsdk in our caches, totaling around 4.2 GB just from 4.x, and for 3.x just one but 710 MB, so around half of our cache allotment is taken up just by that currently

SHEESH! And here I was splitting hairs over cache efficiency with godot-cpp/plaintext, when this was effectively capping us at 5GB all this time

[AThousandShips]

I'll do some further experimentation with the action and see if we can do some specific caching to help with it, and especially looking into if we can cache the generated system symbols

The latter should be possible to cache along with the SCons cache

Having a single emsdk cache for each branch and version only fetched on PRs should be possible with the system but will see

[AThousandShips]

Discovered an alternative option will investigate

Not trivial to set up so will follow up if I can resolve it

[akien-mga]

I'll do some further experimentation with the action and see if we can do some specific caching to help with it, and especially looking into if we can cache the generated system symbols

To be clear, I'm not necessarily saying caching the system symbols is worth it. We should measure how long it takes to generate. If it's less than 15s there's really no need to add extra caching just for that.

[Repiteo]

Thanks!

[AThousandShips]

Thank you!