meta: do not set a version string for cache entries of shared build workflows

[Renegade334]

meta: use SCCACHE_GHA_ENABLED for shared build workflows

The test-shared workflow currently sets SCCACHE_GHA_VERSION=on; while this (non-canonically) enables the GHA cache, it also appends "-on" to the version tag of every uploaded cache entry, which prevents any cache entries from being shared with the non-shared workflows. Using the canonical SCCACHE_GHA_ENABLED doesn't overwrite the version string, which means that shared and non-shared builds can share cache hits where available.

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[targos]

LGTM but I don't think this will actually have an impact. Builds are too different.

[richardlau]

which prevents any cache entries from being shared with the non-shared workflows.

I have no idea how sccache works, but for ccache (used in Jenkins) sharing cache between shared and non-shared builds doesn't give any benefits because the arguments passed to the compiler/linker are different. If anything this will probably end up causing earlier eviction of cache entries that could have been reused.

[Renegade334]

If anything this will probably end up causing earlier eviction of cache entries that could have been reused.

This will cause one-time invalidation of the shared build cache, for sure. Beyond that, it should be zero-impact at worst.

[richardlau]

If anything this will probably end up causing earlier eviction of cache entries that could have been reused.

This will cause one-time invalidation of the shared build cache, for sure. Beyond that, it should be zero-impact at worst.

I meant that if sccache is like ccache, then sharing the cache would lead to, e.g.

1. Non-shared build runs. Populates cache.
2. Shared build runs. Results are different from previous non-shared run (due to differing arguments to the compiler/linker). So new entries added to cache. If cache hits size limit (does sccache have those?) then older cache entries (e.g. from the previous non-shared build runs) are evicted.
3. New non-shared build runs. If results from 1. have already been evicted the benefits of caching are now negated.

[Renegade334]

I meant that if sccache is like ccache, then sharing the cache would lead to, e.g.

1. Non-shared build runs. Populates cache.
2. Shared build runs. Results are different from previous non-shared run (due to differing arguments to the compiler/linker). So new entries added to cache. If cache hits size limit (does sccache have those?) then older cache entries (e.g. from the previous non-shared build runs) are evicted.
3. New non-shared build runs. If results from 1. have already been evicted the benefits of caching are now negated.

Probably poor nomenclature on my part – the cache storage itself (including any eviction limits) is shared between all our GHA builds irrespective of the version field in the entries, the version field is just metadata on the GHA storage side that enforces a cache miss on mismatch even if the keys match. So, shared and non-shared builds are currently guaranteed not to retrieve cache artifacts from the other – which will likely not change much, granted, but there's no real downside to this change either.