[SERVER-66134] Code Coverage build variants in Evergreen still aren't archiving code coverage data Created: 03/May/22  Updated: 29/Oct/23  Resolved: 07/Jun/22

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Ryan Egesdahl (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-60832 Code Coverage variant not generating ... Closed
is related to SERVER-63055 gcov and clang cause failures in Vali... Closed
is related to SERVER-67064 Investigate further fixes to coverage... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Dev Platform 2022-05-30, Dev Platform 2022-06-13
Participants:

 Description   

I looked over recent code coverage builds and didn't see a tarball containing the code coverage data being uploaded to S3. An error message in the task logs suggests at least some part of the issue is an Evergreen expansion not being set.

[2022/05/01 05:29:40.175] Running command 'subprocess.exec' in "save code coverage data" (step 11.2 of 22)
[2022/05/01 05:29:40.176] No coverage tool defined. Set the gcov_tool expansion in evergreen.yml
[2022/05/01 05:29:40.176] Command failed: error waiting on process '7d86f7a4-6375-4466-9488-a43a1252029f': exit status 1

However, even prior to the changes from 05ea833 as part of SERVER-63055, it doesn't look like there's a "gcov intermediate files" tarball. For some reason there's a "Hang Analyzer Output" tarball containing one of the .gcda files though.

% tar -tf ~/Downloads/mongo-hanganalyzer-mongodb_mongo_master_enterprise_rhel_80_64_bit_coverage_v4gcc_57b670b4df8b5ad731306a811500b46c9e71a0e9_22_03_26_15_32_54-jsCore-0.tgz
debugger.gcda.gcov.json.gz

https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_80_64_bit_coverage_v4gcc_jsCore_57b670b4df8b5ad731306a811500b46c9e71a0e9_22_03_26_15_32_54



 Comments   
Comment by Ryan Egesdahl (Inactive) [ 07/Jun/22 ]

Since the work this ticket was set out to do is basically done, I have opened SERVER-67064 to track the remaining work. I expect that we will need to replace our processor script, which isn't a huge amount of work, but it's probably more than what I would want to continue on with in this ticket.

Comment by Ryan Egesdahl (Inactive) [ 31/May/22 ]

max.hirschhorn@mongodb.com Could you please describe the remaining issues? This ticket was mainly focused on making sure the intermediate files were available. I wasn’t aware there were other issues to be resolved.

Comment by Max Hirschhorn [ 31/May/22 ]

Reopening this ticket at least until we track the remaining issues around the code coverage variants in Jira (or fix them under this ticket).

Comment by Githook User [ 31/May/22 ]

Author:

{'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}

Message: SERVER-66134 Fix missing GCOV_TOOL env var
Branch: master
https://github.com/mongodb/mongo/commit/f9ed329b632fafb67093baf462add99777f49854

Comment by Ryan Egesdahl (Inactive) [ 26/May/22 ]

All of this got merged right around when we were doing a lot of changes to evergreen.yml, and it looks like setting the GCOV_TOOL variable that the script relies on inadvertently got dropped while resolving the merge conflicts. I'm hoping all I need to do is restore that, but I will also check to make sure the files are being put in the correct archive as well.

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