You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using Tuist Cloud, and specifically binary cache, the cache is sensitive to the specific configuration your app/tests/etc are using. This is a very subtle detail which can make your cache entirely not work, silently, and it is quite hard to catch it happening.
tuist cache and tuist generate by default use the Debug configuration to my understanding, which means that if you locally build with a custom configuration, running tuist generate MyApp will try to grab the cache of the wrong configuration - but you will never know that's the case :)
You need to specifically do tuist cache -c myConfig , tuist generate -c myConfig MyApp - if you know that's an issue.
I think this isn't an issue only from the configuration perspective, but also practically from the perspective a developer most likely doesn't know this minor detail.
Potential solution
At the bare minimum some way to specify a default configuration for these commands (in Config.swift). Not sure if this should apply to the general config or to the cloud one, since I'm unsure if it's even needed outside of cloud.
I'm leaning towards adding it to the cloud config but also make it required to specify so this situation doesn't occur by default, and also developers are more aware of the fact thinking about per-configuration caching is required (maybe a documentation update could also be relevant).
macOS version
14.4.1
Tuist version
4.11
Xcode version
15.3
The text was updated successfully, but these errors were encountered:
PS - this is a "nice to have" but it could also be nice to allow to (optionally) specify the default target.
For most companies this will be the main app, so they can write tuist generate and get tuist generate MyAwesomeApp by default, which helps for this "happy path", quite a lot.
For most companies this will be the main app, so they can write tuist generate and get tuist generate MyAwesomeApp by default, which helps for this "happy path", quite a lot.
This doesn't make that much sense for local workflows where generating just the App target is not that useful. Adding a default app for CI workflows only does not bring a lot of value since that's specified once in your CI pipeline.
What problem or need do you have?
When using Tuist Cloud, and specifically binary cache, the cache is sensitive to the specific configuration your app/tests/etc are using. This is a very subtle detail which can make your cache entirely not work, silently, and it is quite hard to catch it happening.
tuist cache
andtuist generate
by default use theDebug
configuration to my understanding, which means that if you locally build with a custom configuration, runningtuist generate MyApp
will try to grab the cache of the wrong configuration - but you will never know that's the case :)You need to specifically do
tuist cache -c myConfig
,tuist generate -c myConfig MyApp
- if you know that's an issue.I think this isn't an issue only from the configuration perspective, but also practically from the perspective a developer most likely doesn't know this minor detail.
Potential solution
At the bare minimum some way to specify a default configuration for these commands (in Config.swift). Not sure if this should apply to the general config or to the cloud one, since I'm unsure if it's even needed outside of cloud.
I'm leaning towards adding it to the cloud config but also make it required to specify so this situation doesn't occur by default, and also developers are more aware of the fact thinking about per-configuration caching is required (maybe a documentation update could also be relevant).
macOS version
14.4.1
Tuist version
4.11
Xcode version
15.3
The text was updated successfully, but these errors were encountered: