-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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): add cache flag #9348
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
8 Skipped Deployments
|
b9eea2e
to
8fb5b84
Compare
bfa85f1
to
02f4bfc
Compare
02f4bfc
to
b5ffd7a
Compare
b5ffd7a
to
0adcd94
Compare
0adcd94
to
0ee6787
Compare
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.
I'm excited for this, biggest thing I'd like to see is some tests regarding how the new cache
struct gets resolved wrt existing cache config settings.
crates/turborepo-lib/src/opts.rs
Outdated
@@ -362,16 +358,37 @@ impl<'a> TryFrom<OptsInputs<'a>> for ScopeOpts { | |||
impl<'a> From<OptsInputs<'a>> for CacheOpts { | |||
fn from(inputs: OptsInputs<'a>) -> Self { | |||
let is_linked = turborepo_api_client::is_linked(inputs.api_auth); | |||
let skip_remote = if !is_linked { | |||
true | |||
let mut cache = inputs.config.cache(); |
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.
I think this layering logic is confusing since env vars or config settings can override CLI level cache settings:
e.g. TURBO_FORCE=1 turbo run build --force=false
would result in remote:rw,local:rw
cache behavior, but TURBO_REMOTE_ONLY=1 turbo run build --cache='local:rw
would result in no caches are enabled.
I think it would make more sense to fold the existing cache flags into the new cache struct at each level in the config, but I'm not convinced that wouldn't be confusing. Could we get away with having the new cache struct conflict with existing cache flags at each level e.g turbo run build --remote-only --cache='...'
would throw but TURBO_REMOTE_ONLY=1 turbo run build --cache='...'
be fine where --cache
wins out completely?
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.
Is there a way to have a group of flags conflict with a single flag but not with each other? I wasn't sure if that's possible in clap. Ofc I can manually add that as a restriction
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.
The layering issue is a tricky one. If the config specifies remote:rw
in a file, but then we add on local:rw
, do we want to do an OR
or an AND
for those? I could see either one working
a485d73
to
a7f05c9
Compare
a7f05c9
to
1470a4d
Compare
…tween existing flags and cache flag
Also fix up config loading
…on't have to worry about layering
9c99caf
to
da88747
Compare
Description
Adds a cache flag that lets you set cache permissions per cache type and per action (read or write)
Testing Instructions
Adds tests in
turborepo_cache/src/config.rs
for parsing and inturborepo-lib/src/opts.rs
for loading and resolving