-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Slight build improvements #675
Changes from 10 commits
e6ba788
7e9875f
0b1d0f3
e14fe8e
5b60541
2f817b7
bde57e3
b8c24ee
21b537f
441bf46
9c5dfa8
c3d8be7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,6 +14,7 @@ npm_run_build { | |
inputs.file 'package.json' | ||
inputs.file 'package-lock.json' | ||
|
||
outputs.cacheIf { true } | ||
outputs.dir project.buildDir | ||
} | ||
assemble.dependsOn npm_run_build | ||
|
@@ -27,6 +28,3 @@ task test(type: NpmTask) { | |
inputs.file 'package-lock.json' | ||
} | ||
|
||
clean { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this is correct to do that. The clean should give us the guarantee that we're starting from a clean slate. Maybe the solution is to not call clean when we build in CI There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
w.r.t performance, removing WDYT? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK then, I am sold! |
||
delete "${projectDir}/node_modules/" | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,3 @@ | ||
org.gradle.parallel=true | ||
org.gradle.caching=true | ||
org.gradle.vfs.watch=true |
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.
What trade off are we making here?
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.
if none of the inputs have changed since the last time we built, but the build artifacts are not present in this current build (which would happen if PR#1's build generated the react app, then PR#2 makes a totally unrelated change) then we can re-use the output from PR#1's build instead of rebuild. Since building the react app takes 40-50s (see example in this build scan). this saves a non-trivial amount of time.
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.
Although (and maybe this is the point you were initially making) since the caching is decoupled from the actual system building the code (npm) new inputs could be added without gradle realizing, and this would result in incorrect artifacts.
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.
Does it mean it is safe or unsafe?
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.
ultimately no because Gradle and NPM can go out of sync (one day we could add a new "source" directory that is no longer reflected accurately by the inputs specified in Gradle), for safety I'll remove it.