Turn hlint-scan into a status check
chungyc opened this issue · 5 comments
The workflow currently does not fail unless there is an error while running hlint or uploading scanning results. This means that the existence of a warning from hlint will not cause the workflow to fail, i.e., the status check will pass.
Make the workflow as a whole fail by default when there is an hlint warning so that it can be used as a status check, and add an option to disable this behavior.
No activity with issue for 90 days.
I don't agree that this should be a default behavior - I actually like when linters or code formatting checks do not make a CI fail, so this should be configurable.
Making CI fail on such is a major annoyance for contributors that are forced to do additional round-trips because a CI failed on e.g. hlint or ormolu - if this is a projects requirement and CI enforces it, it should also be a part of pre-commit hook.
On GitHub you can make the workflow as optional (by making others as required), so even if it fails, the PR can still be merged.
(and there's always the option to force merge, though in general frowned upon)
On GitHub you can make the workflow as optional (by making others as required), so even if it fails, the PR can still be merged.
I'm aware but my tooling only creates a single workflow for now until I do sorki/github-actions-dhall#16
Anyway I can always disable it (if the flag is there) so I don't mind.
And only now do I realize that hlint-scan doesn't have to do anything. GitHub already treats code scanning issues as status checks, except they are gated by severity. The default severity that code scanning status checks fail is "error" or higher, and most HLint hints are "warning" or lower, but the threshold can be lowered.