[SERVER-25691] Break out unit test compilation and run in its own task Created: 18/Aug/16  Updated: 08/Jan/24  Resolved: 22/Dec/16

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: 3.4.15, 3.5.2

Type: Improvement Priority: Major - P3
Reporter: Daniel Pasette (Inactive) Assignee: Eddie Louie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-27483 Avoid stripping debug symbols from C+... Closed
Problem/Incident
causes SERVER-27529 scons msi target is failing do to mis... Closed
Related
related to SERVER-33963 Use an Evergreen task group for compi... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.4
Sprint: TIG 2017-01-02
Participants:
Linked BF Score: 0

 Description   

Building unit tests takes a large portion of the overall compile time, but are needed only once. This delays our ability to run the tests that only depend on mongod, mongos, mongo shell and the tools. This will cut overall regression suite end to end time down significantly.



 Comments   
Comment by Githook User [ 29/Mar/18 ]

Author:

{'email': 'eddie.louie@mongodb.com', 'name': 'Eddie Louie', 'username': 'elouie99'}

Message: SERVER-25691 Create separate compile task for building most commonly-used binaries

(cherry picked from commit 41e2509b97f9f8c20d6a7ce6c3dafbbb4edbdd89)
Branch: v3.4
https://github.com/mongodb/mongo/commit/8e664ae0a26ed0be84996053e98c9858ac08ee7c

Comment by Githook User [ 22/Dec/16 ]

Author:

{u'username': u'elouie99', u'name': u'Eddie Louie', u'email': u'eddie.louie@mongodb.com'}

Message: SERVER-25691 Create separate compile task for building most commonly-used binaries
Branch: master
https://github.com/mongodb/mongo/commit/41e2509b97f9f8c20d6a7ce6c3dafbbb4edbdd89

Comment by Eddie Louie [ 21/Dec/16 ]

Code review link: https://mongodbcr.appspot.com/103960002/

Comment by Max Hirschhorn [ 21/Dec/16 ]

Why can't we build/run the unit tests on the same machine in a single task? Then we could potentially leave them unstripped and upload the failing ones to s3 for further analysis with debug info!

For what it's worth, I've got a good number of very intermittent integration test failures that are otherwise un-debuggable that would also benefit from this treatment.

So this isn't just a make compile faster thing, it's also a: "make it possible to debug build failures" thing.

jonathan.reams, mira.carey@mongodb.com, I think these are some good points - I've filed SERVER-27483 to capture the work to fold the unittests task into the compile_all task, which will be scheduled for immediately after this ticket is resolved.

Comment by Mira Carey [ 25/Aug/16 ]

For what it's worth, I've got a good number of very intermittent integration test failures that are otherwise un-debuggable that would also benefit from this treatment.

So this isn't just a make compile faster thing, it's also a: "make it possible to debug build failures" thing.

Comment by Jonathan Reams [ 19/Aug/16 ]

Why can't we build/run the unit tests on the same machine in a single task? Then we could potentially leave them unstripped and upload the failing ones to s3 for further analysis with debug info!

Comment by Andrew Morrow (Inactive) [ 18/Aug/16 ]

And, of course, we can't do dynamic linking on Windows, at all.

Comment by Andrew Morrow (Inactive) [ 18/Aug/16 ]

Also, if you built the unit tests in dynamic mode, you wouldn't re-use the objects from building mongos and friends.

Comment by Andrew Morrow (Inactive) [ 18/Aug/16 ]

We can't, quite yet, because dynamic aren't relocatable, yet. We could, if we had an evergreen facility to state that to jobs should run on the same instance, but we lack that feature.

Comment by Mathias Stearn [ 18/Aug/16 ]

Additionally, we should consider building the unit tests (and integration tests, dbtest, etc) using dynamic linking, even on variants that use static linking for mongo, mongos and mongod.

Generated at Thu Feb 08 04:09:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.