NikoLight
NikoLight copied to clipboard
TheRealKasumi
DevOps: Linting
Currently, it is set to lint everything on all branches and all pushes. Uses clang for c++. Yeah, it will fail on your crazy double spaces @TheRealKasumi :-)
I will check for conflicts a little later :) . But I can already say thank you. We really needed this!
Short comment why this is still open. I need to find time at some point create a compatible vs code config for the formatting. Otherwise we will run into constant conflicts when merging this.
I need to find time at some point create a compatible vs code config for the formatting. Otherwise we will run into constant conflicts when merging this.
I tend to disagree with this currently. A developer should use appropriate linters during the development (in our case for example: markdownlint, clang-format, shell-format, ... ). Surely we can provide a complete VS Code development environment as a dev container, but on the one hand we limit developers to VS Code and on the other hand the current number of active developers does not justify the effort.
Linting while pushing is the final check. Normally, nothing should be found this late. And we have a final check to have only linted code in our repo.
A developer should use appropriate linters during the development
Which usually requires a proper configuration of the linter which should be provided by the project. Right now we are checking against which config/rules? Some default config/rules? When applying this, who gives me the guarantee that the code doesnt look like trash afterwards ^^* ? Who gives me the guarantee that there are no conflicts with line endings ect? So I am little careful with that before I found time to really try it out.
limit developers to VS Code
Not limit them to vs code but give them a config they can easily use in case they also use vs code. Otherwise they are free to use their own code editor and run the linter manually. But here again, then we should provide a proper configuration for each linter used.
Normally, nothing should be found this late
Which is why I like to have a proper vs code config so that it is applied on save automatically for example.
Agree and I do not see why not implementing this linting gate. It is not an automatic linter. If state-of-the-art linting rules are not fulfilled, the check does not pass and the branch is not able to be merged.
We can limit to pull requests in the first step if you prefer and not on your commits on main :-) When linting test is not passed, the merge is not possible and need another commit with correct linting.