[SERVER-65581] Errors reported from ESLint/ClangTidy are extremely difficult to locate Created: 13/Apr/22  Updated: 29/Oct/23  Resolved: 31/May/22

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

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Richard Samuels (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-67651 Errors reported from the new clang-ti... Closed
related to SERVER-73308 Capture npm output written to stderr ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Dev Platform 2022-05-16, Dev Platform 2022-05-30
Participants:

 Description   

The eslint task outputs about 500 lines of log output of which only a couple are the actual error.

In this example, the actual error is buried somewhere in the middle and is in the same colour as the rest of the log, therefore extremely hard to visually locate:

[2022/04/13 17:42:27.190] ERROR: ESLint found errors in /data/mci/eaab7ae7f0a51a1517947dd4ea3b7365/src/jstests
[2022/04/13 17:42:27.190] b"/data/mci/eaab7ae7f0a51a1517947dd4ea3b7365/src/jstests/sharding/safe_secondary_reads_single_migration_waitForDelete.js:529:17: Duplicate key '$or'. [Error/no-dupe-keys]\n\n1 problem\n"
[2022/04/13 17:42:27.190] ERROR: ESLint found errors. Run ESLint manually to see errors in files that were skipped

This is not an issue with just ESLint, ClangTidy has the same problem and outputs even more log, some of which is highlighted in red, but this is a "red herring".

We should do a better job at highlighting these errors.

Perhaps we can remove some of the other log which is being reported as part of the task and redirect it to a different tab. For example, not sure why as someone who is changing code in the core server do I need to see this:

[2022/04/13 17:42:28.200] Finished 'subprocess.exec' in "upload npm logs" in 146.226483ms
[2022/04/13 17:42:28.200] Running command 'archive.targz_pack' in "upload npm logs" (step 2.3 of 22)
[2022/04/13 17:42:28.201] Finished 'archive.targz_pack' in "upload npm logs" in 578.814µs
[2022/04/13 17:42:28.201] Running command 's3.put' in "upload npm logs" (step 2.4 of 22)
[2022/04/13 17:42:28.221] Putting private files into s3
[2022/04/13 17:42:28.221] performing s3 put of a hidden file
[2022/04/13 17:42:28.221] Command failed: missing file '/data/mci/eaab7ae7f0a51a1517947dd4ea3b7365/npm-logs.tgz': problem opening file /data/mci/eaab7ae7f0a51a1517947dd4ea3b7365/npm-logs.tgz: open /data/mci/eaab7ae7f0a51a1517947dd4ea3b7365/npm-logs.tgz: no such file or directory
[2022/04/13 17:42:28.221] Finished 's3.put' in "upload npm logs" in 20.538546ms



 Comments   
Comment by Richard Samuels (Inactive) [ 31/May/22 ]

This change generates reports for our lint_* tasks and clang_tidy. Here's a sample log from clang_tidy that shows that we isolate the logs into the tests section, and also discard much of the noise (e.g. "[n] warnings generated"). For clang_tidy, we also remove duplicate error messages, such as those that emerge when an error is introduced in a header included by multiple translation units.

For the existing lint_* tasks, we just isolate the stdout from the linter.

Comment by Githook User [ 20/May/22 ]

Author:

{'name': 'Richard Samuels', 'email': 'richard.l.samuels@gmail.com', 'username': 'richardsamuels'}

Message: SERVER-65581 generate report files for linters
Branch: master
https://github.com/mongodb/mongo/commit/09173712c719030f4c1ee499578e25d10fbc536f

Comment by Richard Samuels (Inactive) [ 16/May/22 ]

Logs will be ingested as a single line by our changes for this ticket. Please see EVG-16886 for a bug fix I've requested.

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