[SERVER-38315] Resmoke should normalize test file paths in test results Created: 29/Nov/18  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Yves Duhem Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Unresolved Votes: 0
Labels: tig-resmoke
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Tooling & Methods
Participants:

 Description   

The test results produced by resmoke are sent to Evergreen.
Having different test paths on Windows and Unix-like systems causes the tests to be distinct from Evergreen's perspective.
This makes getting test statistics or history harder for these tests.
The test paths should be normalized before being included in the results.



 Comments   
Comment by Steven Vannelli [ 10/May/22 ]

Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions.

Comment by Andrew Morrow (Inactive) [ 03/Dec/18 ]

A long term better approach is to standardize the installation prefix for the tests, under hygienic builds.

Comment by Max Hirschhorn [ 01/Dec/18 ]

Other work we may want to consider as part of this ticket would be to standardize the VARIANT_DIR that's used for compiling the C++ unit tests across all build variants. This may effectively already be happening as a result of the shared SCons cache work so we don't need to make any further changes. CC acm

Comment by Max Hirschhorn [ 01/Dec/18 ]

The work on this ticket would be to have the "test_file" property in the report.json file be normalized according to the rules in TestHistory._normalize_test_file().

I think we would want to preserve the platform-specific pathname as a new property in the report.json file (that Evergreen would simply ignore) in order to facilitate doing SERVER-21074 or other work to rerun failed tests in the future.

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