Closed LenaWil closed 1 year ago
Okay, that didn’t work like it was supposed to.
Patch coverage: 100.00
% and no project coverage change.
Comparison is base (
91de163
) 95.69% compared to head (a674ad1
) 95.69%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Naar editorconfig kijken
I don't think we want the lint-check-full
job to run, as it looks for linting problems across the whole repository. The resulting workflow output is so large that it doesn't offer any clarity. We can reconsider this in the future, when we will probably have less linting problems.
I can't tell whether lint-changed
is actually working. Perhaps you could add a (purposefully wrongly formatted) Python file to this PR to showcase what the workflow would do/show? Food for thought: Is it needed to have this run on every push, instead of just PRs?
Is there any extension/bot that'll need to be installed for these workflows? If so, I can add them.
- I don't think we want the
lint-check-full
job to run, as it looks for linting problems across the whole repository. The resulting workflow output is so large that it doesn't offer any clarity. We can reconsider this in the future, when we will probably have less linting problems.
Do you want me to remove the code, or just put if: false
there?
- I can't tell whether lint-changed is actually working. Perhaps you could add a (purposefully wrongly formatted) Python file to this PR to showcase what the workflow would do/show?
Can do that?
Food for thought: Is it needed to have this run on every push, instead of just PRs?
I could disable it? If you want to?
I had enabled it because it only checks for the changes in one commit when running on pushes, and thus is different from the pull requests run.
- Is there any extension/bot that'll need to be installed for these workflows? If so, I can add them.
lint-git-pr-comments-action-suggester needs reviewdog, but later I was thinking how useful it would really be, because it only reacts on the lines of the files and not the rest of them. Then I was thinking if formatting the files wouldn’t generate a lot of noise in the diffs of pull requests, but I didn’t really have a better solution, other than doing everything in one try.
Speaking of, there are multiple ways to to configure reviewdog, like by code suggestions, or just warnings on the files themselves. Any preferences?
Fixes #13.
We should probably discuss more what kind of linter we want and how we would implement it without giving everyone merge conflicts, but here is a concept.I went with adding black as a GitHub action that only checks the files changed in the pull request itself, setting it up to check only lines was complicated, and also as a GitHub action that checks all of them. Please say if I should remove the last one. Furthermore I added a review bot for it; in the case the code is only a few lines wrongly formatted it would be easier to fix. However, the permissions don’t work correctly with the main repo, so I need to check that with someone with more permissions, if we even want it.