-
Notifications
You must be signed in to change notification settings - Fork 990
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem matchers do not work on colored output #2341
Comments
ian-h-chamberlain
added a commit
to corewa-rs/corewars
that referenced
this issue
Dec 25, 2022
Workaround for actions/runner#2341 I guess... Color output would be nice but annotations seem nicer.
ruvceskistefan
added
the
keep
Label can be added as soon as we are sure the work on the issue is necessary
label
Dec 26, 2022
@ruvceskistefan since you triaged this to add the |
jonasbb
added a commit
to actions-rust-lang/setup-rust-toolchain
that referenced
this issue
Mar 17, 2023
The action runner currently fails to strip color codes from the output. This means that many matchers currectly do not work. actions/runner#2341 actions/runner#2430 The new matcher is copied from kaj/rsass which is MIT licensed. https://github.com/kaj/rsass/blob/3e5d6c0600324fe27b0a0257d3befd4bb345fedb/.github/workflows/rust-problem-matcher.json
kodiakhq bot
pushed a commit
to chdsbd/foodieyak
that referenced
this issue
Apr 3, 2023
We don't support colored output because of a bug in GitHub Actions: actions/runner#2341
jmarrec
added a commit
to jmarrec/test-Github-Actions
that referenced
this issue
Jun 20, 2023
…h (cf actions/runner#2341 - problem matcher do not work on colored output)
toofar
added a commit
to qutebrowser/qutebrowser
that referenced
this issue
Nov 19, 2023
We think that at some point pytest added color codes to the summary output which broke these matcher regex. It looks like there is an issue about stripping color codes here: actions/runner#2341 I've added wildcard (or no-space) elements instead of trying to match the color codes exactly (eg `\033\[31m` etc) because 1) that's not very readable 2) I was having trouble getting that to work with egrep. The goal is to match the target strings but not to match then later in the line as part of a test log or whatever. For the '= short test summary =' that should be pretty unique. For the ERROR|FAILED I reckon that could be a bit more common. I'm just matching with any mount of non-space characters because I reckon a space will crop up pretty early in any line where ERROR isn't the first work. I think this new matching will only apply to new or rebased PRs after it is landed.
toofar
added a commit
to qutebrowser/qutebrowser
that referenced
this issue
Nov 19, 2023
We think that at some point pytest added color codes to the summary output which broke these matcher regex. It looks like there is an issue about stripping color codes here: actions/runner#2341 I've added wildcard (or no-space) elements instead of trying to match the color codes exactly (eg `\033\[31m` etc) because 1) that's not very readable 2) I was having trouble getting that to work with egrep. The goal is to match the target strings but not to match then later in the line as part of a test log or whatever. For the '= short test summary =' that should be pretty unique. For the ERROR|FAILED I reckon that could be a bit more common. I'm just matching with any mount of non-space characters because I reckon a space will crop up pretty early in any line where ERROR isn't the first work. I think this new matching will only apply to new or rebased PRs after it is landed. ref: #5390 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Color codes appear to affect regex matching of problem matchers
To Reproduce
Steps to reproduce the behavior:
"regexp": "Hello world"
bash -c "printf '\e[31mHello\e[0m world!\n'"
As a more real-life example, I have created a minimal reproduction with colored output and missing the expected annotations:
https://github.com/ian-h-chamberlain/actions-color-repro/actions/runs/3777593125
However, when I updated the workflow to disable color output, annotations appear as expected:
ian-h-chamberlain/actions-color-repro#1
https://github.com/ian-h-chamberlain/actions-color-repro/actions/runs/3777594485
Expected behavior
Most (all?) are written against plain (un-colored) text, but it would be nice to have colorized output in the action logs while still supporting colored output.
This document indicates that color codes should be stripped before applying matchers.
Runner Version and Platform
Version of your runner?
Current runner version: '2.299.1'
OS of the machine running the runner?
ubuntu-latest
What's not working?
See the "expected behavior" above.
Other notes
I believe this logic is incomplete for stripping ANSI color codes:
runner/src/Runner.Worker/Handlers/OutputManager.cs
Line 19 in a1244d2
runner/src/Runner.Worker/Handlers/OutputManager.cs
Line 100 in a1244d2
Here is a sample logs from a more realistic run which I believe show a wider range of ANSI control codes that might be encountered by tools that use color: 6_Run clippy linting.txt
The text was updated successfully, but these errors were encountered: