Optimize caching versioning

[danieleformichelli]

Hello 👋
Right now we are adding the Tuist version as part of the target hash calculation.

While this is the safest possible approach and make sure that the cached framework is “aligned” with the current Tuist version, it invalidates the cache much more often than needed, as a Tuist update should actually invalidate the cache only if it changes how it maps from a TuistGraph.Target to a .framework/.xcframework (correct me if I’m wrong).
This means that either teams rebuild the caches more often than needed or they don’t update Tuist too often to avoid that.

As an alternative approach, we could just not make the Tuist version part of the hash calculation, and instead use an independent version, which changes only if there is a real reason to invalidate the cache (i.e. it actually changes how Tuist maps from a TuistGraph.Target to a .framework/.xcframework).

What do you think?

[adellibovi]

I don't feel confident about this approach.
We would need to maintain a separate version number that would only change when the generation of the project changes, in my opinion, this could be quite error-prone (we would need to remember for every PR merged) and, if we forget about it, it will behave like pre-having tuist version for hashing.
Personally, I prefer to be on the safe side and keep the hashing as it is, also I can't think of other alternatives, sorry.

[adellibovi]

Actually @danyf90 , could you explain better what you mean for the first option? Maybe I didn't fully understand it

[danieleformichelli]

I agree it's less safe, the reason why I am in favor of it is that changing that part of Tuist is not super common, and in case we forgot to "bump it" the consequences are not catastrophic.
For comparison, I think it's much more probable that we add a new field to the ProjectDescriprion and we forgot to update the caching logic to take it into account, and we don't have any countermeasure for that

[adellibovi]

After talking with @danyf90 , I changed a bit my view on this topic. While it may be true that today we do not have something in place to easily detect when "generation" changes and requires a new version, I believe those are things we can fix separately and with different approaches. In general, it DOES make sense to me to use a specific version for caching generation.
In short, I would be okay with the suggested approach. Thanks @danyf90

[fortmarek]

This is an interesting idea. If some teams try to stay on the latest version, it will lead to a lot of rebuilding of the cache that is not necessary. If we're able to confidently determine which parts of our codebase will influence the hashing mechanism, we could have some automation in fourier that would regenerate a string in Constants.swift based on the sources. If we do this, we should maybe try to create some acceptance tests that will ensure that the compiled frameworks are indeed compatible with the next tuist version if we don't recompute the hash in Constnats.swift. However, it's a tricky trade-off as it will be more code we will have to maintain and which will never 100 % bulletproof. I'd like to hear from some other folks as well. cc @tuist/core

[fortmarek]

We can just target TuistCache directory. It will again include false positives but it will lead to a whole lot less of them than the current approach. Or do you think code from other features might influence that? I presume TuistSupport and TuistCore could, so maybe it's not the best approach after all but I'd love to automate it somehow.

[danieleformichelli]

I think the target hashing logic covers up to the definition of TuistGraph.Target.
After that, we have the logic to:

• map from TuistGraph to actual Xcode project <- part of TuistKit/Generator
• map from Xcode project to a framework/xcframework <- part of TuistCache

Maybe we can add the TuistKit/Generator and TuistCache folders as part of the check (not sure if others should be added as well).
To reduce false positive (i.e. invalidating the cache without an actual reason) I would just add a warning in CI every time a file in those directories changes, but the "cache version" doesn't change, instead of automatically bumping such version

[fortmarek]

If we are able to specify individual files, we could do so as well. I'm fine with just doing a warning on CI but I think we should really find a way to automate this at least partly.

[danieleformichelli]

I have changed the logic here.
Do you have some pointers on how to add the check in CI? Otherwise feel free to add it on that branch if you want 🙌

[fortmarek]

You should be able to gather which files have changed and then compare that with the ones we think should change the hash. You'd compare that and if there was an intersection, then you'd check if a hash changed -> if not, we'd create an error. You could then explicitly specify e.g. in the Github PR title/description that you wanna skip this check as you are sure it should not be changed.

This is a very rough idea, I'm open to discussing this further if you want to 👌