Closed Bug 1334940 Opened 3 years ago Closed Last year

Re-enable SCCACHE for linux64-ccov builds

Categories

(Testing :: Code Coverage, defect)

defect
Not set

Tracking

(firefox63 fixed)

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: mitchhentges, Assigned: gabriel-v)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170126200443

Steps to reproduce:

Run a build on taskcluster with sccache enabled. For example, see: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8002f88014f819ce34055db8ecf72c0e1ceb2b4a&selectedJob=68153184 (232kB gcno archive)


Actual results:

The produced "gcno" archive is missing most of the "gcno" files, and is undersized.


Expected results:

Build running with sccache should properly track the "gcno" files. When the final "gcno" archive is created as an artifact, it should be around ~75mB
Depends on: 1334402
Backstory:
1. linux64-ccov builds were producing incomplete gcno issues
2. Cause was determined to be incorrect sccache interaction: https://bugzilla.mozilla.org/show_bug.cgi?id=1332917#c18
3. sccache is being disabled for linux64-ccov builds: https://bugzilla.mozilla.org/show_bug.cgi?id=1334402
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ted, Chris, I think this is pretty important for build times, right? Do you know what kind of improvement would be expected by using sccache?
I've filed https://github.com/mozilla/sccache/issues/258 to add support to sccache.
Flags: needinfo?(ted)
Flags: needinfo?(cmanchester)
Somewhere in this ballpark, presumably:
https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-inbound,1682429,1,2&series=mozilla-inbound,1582370,1,2

The "plain" builds build without sccache (for measuring build system times without the noise introduced by sccache caching). You can see that the "build times opt plain" measurement is fairly consistent, and the "build times opt" measurement (which does use sccache) is quite a bit lower but variable.
Flags: needinfo?(ted)
I don't have any more info on this. As long as they only run in a few configurations I don't think the efficiency of these builds would be a big concern from an infrastructure capacity standpoint.
Flags: needinfo?(cmanchester)
I'm working on https://github.com/mozilla/sccache/issues/258. 

1. Here's a try build without changing anything:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6572946785b53fc9959a28183eb6299195d16cfd

2. Here's a try build that just enables sccache, without patching it (to see if the problem is still there):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f27039c3af59f5524ef9acacb6349951ca8d5c63

3. And here's a try build that uses the patched sccache that I've been working on:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8046c858ca85cc80016e5db6520cd08e99d0015

The gcno archives for build #1 and #3 are roughly the same, 75.9mb. I'll update with build #2 once it's done.
Assignee: nobody → tvijiala
Status: NEW → ASSIGNED
Summary: Re-enable and SCCACHE with linux64-ccov, and configure to not lose "gcno" files → Re-enable SCCACHE for linux64-ccov builds
Interesting enough, build #2 produces a gcno archive of roughly the same size as the other ones, 75.9mb, but it's missing some files. Builds #1 and #3 have the same files.
Comment on attachment 8991977 [details]
Bug 1334940 - Re-enable SCCACHE for linux64-ccov.

https://reviewboard.mozilla.org/r/256876/#review264400

Thanks for fixing the sccache issue!
Attachment #8991977 - Flags: review?(ted) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/f41fb72f94b6
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.