[build-tools] - Gradle build profile report with task execution breakdown#3629
[build-tools] - Gradle build profile report with task execution breakdown#3629AbbanMustafa wants to merge 6 commits into
Conversation
|
Big fan of this, after testing Android builds in Launch and seeing it's roughly 5x as slow for the default Expo template (SDK 54) - amounting for a total of 15m12s just for the gradle step 
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3629 +/- ##
==========================================
+ Coverage 55.70% 56.56% +0.86%
==========================================
Files 852 888 +36
Lines 36549 38468 +1919
Branches 7642 8023 +381
==========================================
+ Hits 20356 21755 +1399
- Misses 14774 16615 +1841
+ Partials 1419 98 -1321 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
⏩ The changelog entry check has been skipped since the "no changelog" label is present. |
AbbanMustafa
changed the title
|
Subscribed to pull request
Generated by CodeMention |
|
|
||
| analytics.logEvent(Event.WORKER_BUILD_SUCCESS, {}); | ||
|
|
||
| if (job.platform === Platform.ANDROID && ctx.env.EXPERIMENTAL_GRADLE_PROFILE === '1') { |
There was a problem hiding this comment.
i've been thinking we may not need to prefix flags with EXPERIMENTAL -- until we document flags i think we can consider them experimental?
| if (profileTasks && profileTasks.length > 0) { | ||
| const report = formatGradleProfileReport(profileTasks); | ||
| for (const line of report.split('\n')) { | ||
| logger.info(line); |
There was a problem hiding this comment.
we could also logger.info(report)? or no?
| env: { ...env, ...extraEnv, LC_ALL: 'C.UTF-8' }, | ||
| }); | ||
|
|
||
| const profileFlag = env['EXPERIMENTAL_GRADLE_PROFILE'] === '1' ? '--profile' : ''; |
There was a problem hiding this comment.
does this impact build performance? could we add it to all builds?
| result: string; | ||
| } | ||
|
|
||
| export async function parseGradleProfile( |
There was a problem hiding this comment.
let's have a separate utility for parsing gradle profiles?
| const html = await fs.readFile(path.join(profileDir, htmlFile), 'utf8'); | ||
|
|
||
| // Find the "Task Execution" section - it's the last <table> in the "Task Execution" tab | ||
| const taskExecMatch = html.match(/<h2[^>]*>\s*Task Execution\s*<\/h2>([\s\S]*?)(?:<\/div>)/i); |
There was a problem hiding this comment.
wouldn't it be nicer to parse the profile as an xml?
| const nameWidth = Math.max(4, ...rows.map(r => r.displayName.length)) + 2; | ||
| const barMaxWidth = 20; | ||
|
|
||
| const header = |
There was a problem hiding this comment.
@hSATAC was formatting a table manually for xclogparsing too… i wonder if there's some kind of utility we could pull in / abstract some logic…
3 participants
Why
We want to give developers visibility into which Gradle tasks are consuming the most build time. This helps them and us identify optimization opportunities, especially when evaluating Gradle caching effectiveness and which modules we can improve.
How
--profileto the gradlew command, which tells Gradle to generate an HTML profile report. We parse this report and display the data in a build phase, broken down by module.parseGradleProfile()which reads the HTML report and extracts task path, duration, and result from the Task Execution tableGRADLE_BUILD_PROFILEbuild phase that logs a formatted table with:BuildResultto returnArtifactsdirectly sincegradleProfileTasksis no longer passed upEXPERIMENTAL_GRADLE_PROFILE=1env varTest Plan
EXPERIMENTAL_GRADLE_PROFILE=1— profile table shows in build logs with correct task grouping and durationsEAS_GRADLE_CACHE=1— module totals and executed tasks display correctly