-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Github action now reports state of execution #3531 #3531
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution. Looks good. I think there is a few things we can clean up here tho. Lets try these, if any of my suggestions don't work, I apologize, just say so.
action/main.py
Outdated
@@ -38,8 +44,23 @@ | |||
base_cmd = [str(ENV_BIN / "black")] | |||
if BLACK_ARGS: | |||
# TODO: remove after a while since this is deprecated in favour of SRC + OPTIONS. | |||
proc = run([*base_cmd, *shlex.split(BLACK_ARGS)]) | |||
proc = run([*base_cmd, *shlex.split(BLACK_ARGS)], stdout=PIPE, stderr=STDOUT) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proc = run([*base_cmd, *shlex.split(BLACK_ARGS)], stdout=PIPE, stderr=STDOUT) | |
proc = run([*base_cmd, *shlex.split(BLACK_ARGS)], stderr=PIPE, encoding="utf8") |
All the output you're after here goes to stderr. You can also set the encoding on the call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding what @ichard26 suggested below, if terminal session here is not utf-8 (which is common in windows?), and i'd re-emit the stderr back to console, wouldn't decoding to utf-8 and then re-encoding back to whatever sys.stdout.encoding was cause possible issues ? Not sure about that - asking for clarification
action/main.py
Outdated
proc = run( | ||
[*base_cmd, *shlex.split(OPTIONS), *shlex.split(SRC)], | ||
stdout=PIPE, | ||
stderr=STDOUT, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proc = run( | |
[*base_cmd, *shlex.split(OPTIONS), *shlex.split(SRC)], | |
stdout=PIPE, | |
stderr=STDOUT, | |
) | |
proc = run( | |
[*base_cmd, *shlex.split(OPTIONS), *shlex.split(SRC)], | |
stderr=PIPE, | |
encoding="utf8", | |
) |
action/main.py
Outdated
_output = proc.stdout.decode("utf-8") | ||
|
||
matches = search(_is_formatted_re, _output, MULTILINE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_output = proc.stdout.decode("utf-8") | |
matches = search(_is_formatted_re, _output, MULTILINE) | |
matches = search(_is_formatted_re, proc.stderr, MULTILINE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for submitting a PR but as it stands currently, this hurts UX in the general case. This captures the output of the Black invocation and never reemits it. That's already not great, but it gets worse. If Black errors out for some reason, the developer reading the logs will have no idea what's wrong since the logs will be almost entirely empty. There are two ways of fixing this:
- Reemit the captured output (always or on a non-zero return code; I'd prefer the former)
- Tee or somehow duplicate the output stream so it can be captured and printed to the console as usual
The second could preserve the colour output and allow for live feedback (unlike the first option), however, I have never done this before so no clue whether this is possible. ASNI codes make it sound really annoying.
I know this Action's output could be improved in general, but that's dependant on GitHub fixing their own infrastructure (which will never happen IME), but if it's possible let's not make it worse.
Also, the general convention for GitHub Actions are to use dashes instead of underscores. Here's an example..
Finally, I'm not keen on using using numbers as boolean, we could use true
/ false
instead. I can go either way on this point though.
I know this is a lot of words, but I do really mean it that I appreciate the effort you've put into this. I'm just one of those "let's right it the first time" folks (un)fortunately :)
# Re-emit stderr back to console so that action output is visible to pipeline | ||
# Do note, click will strip terminal control codes if the output is not TTY | ||
# and thus, this will not show colors anymore. | ||
print(proc.stderr, file=sys.stderr, flush=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im still wondering if i should proc.stderr should match sys.stdout.encoding
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and to give a bit of background, character encoding on github runners with windows as os, is reported to be cp1252
while ubuntu and macos default to utf-8 .. enforcing utf-8 on subprocess.run() feels dirty if the output is going back to windows runner ..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess, using sys.stdout.encoding is prob the better thing to do
- Is there a
sys.stderr.encoding
? - I just know all our output will always be utf8 compliant ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I did miss this swallowing of the output, it's prob better to not encode @ subprocess (like you had it - sorry) and only decode for the regex and reprint the raw bytes. That might preserve the colors etc. too
Another option would be to have black itself check if it's running in a GitHub action environment and if so dump a file or set environment variable(s) actions could use maybe? Then we don't mess with stderr that's designed for humans, not computers, at all. |
Not against rewriting the patch for that if the approach is acceptable ? Less issues to tackle for sure but personal take; approach doesn't feel like "keeping it simple". Anyhuu, I'll make another pr against the core black and if that approach is valid, this pr can be closed. |
Lets give it a few hours for others to see if they like the approach better ... I don't want to eat your time ... I'm also for going this way of people are happy about it ... I just floated my idea as alarm bells always go off in my head when automation is using output designed for humans / wrapping tools if it can be avoided. |
@cooperlees rasjani@367beb8 shows alternative approach baked directly into black itself and not into action .. And don't worry about wasting my time - at the moment - im "in between" customers and doing foss contributions is considered as positive way to spend time on the bench :) |
Your POC commit looks good to me. I feel lets do that and read from the dumped file (I think JSON is a better choice) leaving stderr alone :) |
Description
Adds 2 new outputs to github actions which would allow pipeline maintainer to do conditional steps based on actions black did. These variables include
is_formatted
which defaults to 0 if no changes where made and 1 when files where formatted. Another one ischanged_files
, which defaults to 0 but reports the number of files changed during the action execution.Checklist - did you ...
CHANGES.md
if necessary?