-
Notifications
You must be signed in to change notification settings - Fork 2k
feat(turbo): framework conditionals #9853
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(turbo): framework conditionals #9853
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -33,6 +48,27 @@ impl Framework { | |||
pub fn env_wildcards(&self) -> &[String] { | |||
&self.env_wildcards | |||
} | |||
|
|||
pub fn resolved_env_conditionals( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super minor, but I think we should offer a single method here that combines env_wildcards
and resolved_env_conditionals
so the task hasher just makes one call. It's a lot easier to write tests on that framework methods than task hasher methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call!
ffab583
to
80ae408
Compare
Is there any more info on why VERCEL_DEPLOYMENT_ID has to be part of the build cache for builds with skew protection enabled? This causes a huge increase in build times on Vercel because every task becomes a miss on a new deployment, i.e. there’s no way to reuse remote-cached work in vercel builds if turborepo adds VERCEL_DEPLOYMENT_ID as part of the cache key |
Never mind, I found #10126 |
Description
Support framework conditional env vars
Testing Instructions