The github output format emits github "workflow commands", which the github UI
interprets and uses to annotate source files with the detected errors. These
commands are elided from the full workflow logs, which means that users looking
at these logs cannot see file and line information for pyrefly errors. It would
be ideal if pyrefly could emit both github and full-text output
simultaneously.
I'm happy to submit a PR for this (subject to my company approving the CLA), and
would appreciate some feedback on how to best proceed.
Some history I've found:
- When
github-formatted output was introduced, workflow commands were
automatically emitted in addition to the selected output format when the
environment variable GITHUB_ACTIONS was true.
- That behavior caused a number of problems and was reverted.
Proposals:
- Add a new output format (maybe
full-github?) that emits both github and
full-text outputs.
- Allow arbitrary combinations of output formats.
- make
--[no-]-github-workflow-commands a separate option, orthogonal to --output-format
Of these, I think 1 would be the better choice? 2 seems like it creates a lot of
new "test surface" and its not clear what other use cases might be relevant.
The
githuboutput format emits github "workflow commands", which the github UIinterprets and uses to annotate source files with the detected errors. These
commands are elided from the full workflow logs, which means that users looking
at these logs cannot see file and line information for pyrefly errors. It would
be ideal if pyrefly could emit both
githubandfull-textoutputsimultaneously.
I'm happy to submit a PR for this (subject to my company approving the CLA), and
would appreciate some feedback on how to best proceed.
Some history I've found:
github-formatted output was introduced, workflow commands wereautomatically emitted in addition to the selected output format when the
environment variable
GITHUB_ACTIONSwas true.Proposals:
full-github?) that emits bothgithubandfull-textoutputs.--[no-]-github-workflow-commandsa separate option, orthogonal to--output-formatOf these, I think 1 would be the better choice? 2 seems like it creates a lot of
new "test surface" and its not clear what other use cases might be relevant.