Skip to content
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

Merged
merged 12 commits into from
Oct 22, 2020
Merged

Slight build improvements #675

merged 12 commits into from
Oct 22, 2020

Conversation

sherifnada
Copy link
Contributor

@sherifnada sherifnada commented Oct 21, 2020

What

Small build improvements:

  • Enable Gradle output task caching
  • enable gradle build scans to allow analyzing build performance
  • use default gradle root to get a higher cache hit rate from gradle processes launched from outside workflow.yml

Some of these came up while looking into #621

@michel-tricot
Copy link
Contributor

For this project, you should put the gain in the PR description

Copy link
Contributor

@michel-tricot michel-tricot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to be careful to not introduce uncontrolled state in the build or flakyness because we don't properly detect changes or we use stale cache

@@ -27,6 +28,3 @@ task test(type: NpmTask) {
inputs.file 'package-lock.json'
}

clean {
Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gradle clean removes build artifacts, not downloaded dependencies. Removing this line retains that behavior so this should be in line with gradle convention.

w.r.t performance, removing node_modules forces us to re-run npm install (install deps) after clean even if nothing in the packages.json/lock changed, which takes a non trivial time locally (30s+). This is different than java behavior where running clean removes build artifacts but not dependencies.

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK then, I am sold!

@@ -14,6 +14,7 @@ npm_run_build {
inputs.file 'package.json'
inputs.file 'package-lock.json'

outputs.cacheIf { true }
Copy link
Contributor

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?

Copy link
Contributor Author

@sherifnada sherifnada Oct 21, 2020

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

@sherifnada sherifnada Oct 22, 2020

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.

@@ -14,6 +14,7 @@ npm_run_build {
inputs.file 'package.json'
inputs.file 'package-lock.json'

outputs.cacheIf { true }
Copy link
Contributor

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?

@michel-tricot
Copy link
Contributor

% the webapp output thingy

@sherifnada sherifnada merged commit d159571 into master Oct 22, 2020
sherifnada added a commit that referenced this pull request Oct 23, 2020
@swyxio swyxio deleted the sherif/speedup-build branch October 11, 2022 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants