Task log output is too verbose, difficult to read #950
Labels
Comments
ghost
added
the
dbjorge
changed the title
karanbirsingh
added
the
status: ready for triage
|
This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights! |
asksep
added
status: ready for work
asksep
added this to Ready For Work
in Accessibility Insights feature board (DEPRECATED - DO NOT USE!)
4 tasks
5 tasks
DaveTryon
added
the
status: active
DaveTryon
moved this from Ready For Work
to In Progress
in Accessibility Insights feature board (DEPRECATED - DO NOT USE!)
3 tasks
This was referenced Feb 8, 2022
5 tasks
brocktaylor7
added
status: resolved
ferBonnin
moved this from In Progress
to Done
in Accessibility Insights feature board (DEPRECATED - DO NOT USE!)
DaveTryon
removed this from Done
in Accessibility Insights feature board (DEPRECATED - DO NOT USE!)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
The task log output from both the ADO extension and GitHub action include a ton of noise that users shouldn't need to parse through; the actual actionable information from a run is buried in the middle of the log and not highlighted meaningfully.
Pipelines and Actions both support specific syntax for stdout messages to enable different types of grouping/highlighting/etc; while designing a logger to support the suggestions in this issue, be sure to consider how to handle both systems' different syntax.
Actual vs expected
Actual output from an example run with a required baseline update (case 4 of ado-extension-staging-validation) - 169 lines
An example of what I think this should look like - 46 lines, with grouping and highlighting
Specific suggested improvements
I think each of these would work fine as independent improvements, no need to wait until all of them are done to make incremental progress.
These are all written from the perspective of the ADO extension, but ideally any
##commands would want to be able to use GitHub Actions equivalents there.##[group]summary/##[endgroup]around the "Installing runtime dependencies" section (Fixed in feat(ado-improvements-1): Add group around installing dependencies #1040)##[group]summary/##[endgroup]around the "Running the scan" section (suggested name:Scanning URL http://the-url.com for accessibility issues) (Fixed in feat(ado-improvements-1): Pipeline specific formatting #1051)@types/reactand@types/react-domdependencies to suppress the noise from office-fabric (Fixed in feat(ado-improvements-1): Add types to generated package.json #1038)##[debug]instead of inconsistently usingINFOand[Trace][info] ===(Fixed in feat(ado-improvement-1): Intercept & adjust logging in scan process #1030 )waitForwarning noise, or suppress it by intercepting Puppeteer's console output (Fixed in feat(ado-improvement-1): Intercept & adjust logging in scan process #1030 )##[debug](Fixed in feat(ado-improvement-1): Intercept & adjust logging in scan process #1030 )[Trace][info] ===prefix from the "Scan report saved successfully" message (Fixed in feat(ado-improvement-1): Intercept & adjust logging in scan process #1030 )##[error]and/or##vso[task.logissue type=error]to report it with appropriate highlighting (Fixed with feat(ado-improvements-1): Refactor reporter errors #1046)task.logissue'ssourcepathargument to present the user-actionable error with error highlighting and file context. For example:(Fixed in #1075 )
(Fixed in #909)
The text was updated successfully, but these errors were encountered: