Replies: 1 comment
-
Regarding about code style checking, can we have 2 bash scripts one for formatting, one for linting ? So that if some don't use pre-commit, they can run those scripts before commit without copying and pasting commands from |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This idea is a kind of result of my recent research on GH Actions.
Due to GitHub Actions restrictions on forked repositories, our
code-style
workflow does not work for PRs raised from forks.Possible solutions are:
Accept it
Conditionally ignore failing step. Ask contributors to turn on GitHub Actions for their forks.
Adapt it
Another solution that I want to propose and discuss is to use formatters in check mode, and use those checks for pointing out code style issues using GH Action Logs and Annotations in PR events from a fork. All the auto-formatting still will be available for non-fork events.
For example, I've created the MVP version of
pycodestyle
for GitHub Actions workflows. (we cannot useautopep8
in check mode, so we need to replace it withpycodestyle
)Here is what I am trying to achieve (results from a dummy demo repo):
After style check we have list of errors and warnings:
From that you can jump to a specific file or line:
Logs are grouped for each file
After unfolding you will find detailed info on error
And here is demo run on ignite repo and dummy file "fixme.py":
https://github.com/pytorch/ignite/actions/runs/597334732
So, currently it works only for
pycodestyle
, but I think we can achieve similar behavior forblack
andisort
Beta Was this translation helpful? Give feedback.
All reactions