ci: implement lint & Annoyatron
We want to run a linter on CI submission.
We also want to display nice error messages to the user. Thus, annoyatron is born.
The flow is as follows:
- a MR is submitted and triggers the 'lint' pipeline
- annoyatron gets pinged over https that an MR requires attention
- annoyatron starts running and waits until the MR's pipeline run succeeds or fails
- the lint jobs either succeeds or fails
- annoyatron notices the pipeline passed, and inspects its results to see if the lint pipeline failed or not.
- annoyatron posts a comment, if necessary
Merge request reports
Activity
added 2 commits
added 2 commits
mentioned in merge request !45 (merged)
- Resolved by rahix
Nice! I had thought about adding this as well but had decided against it up to now. The reason is that I dislike using code-style tools as an ultimate source of truth. In some cases, a manually formatted statement just looks better. Apart from this, in our project, we have to deal with a lot of source-files from different projects and I'd prefer to not reformat them.
There's two possible fixes (ideally, a hybrid solution of both) which I have in mind:
- Limit the check (
git diff
) to files inepicardium/
,pycardium/
, andbootloader/
. Maybe addlib/card10/
as well. - Allow failures of this CI-pass, somehow making them not block the MR but still emit an automated warning. My naive idea was to use GitLab API to post a comment but I feared this becoming too complex to be worth it ...
- Limit the check (
While we're at it I could also integrate
black
for python formatting into the tool?I have a much different and tougher opinion on code formatting - if there's a lint diff, it doesn't get merged.
Sure, we can limit the checks to directories we control - but we should agree that linters are sacred and even if you don't like the style they emit. The whole point (especially with black) is that you give away the freedom (and mental burden) of manually formatting code in return for consistency and piece of mind.
If CI just emits a warning and doesn't block then in my opinion it might as well not exist, as people will immediately learn to ignore it.
Hmm, I guess the main reason for me not being that strict is that in some places, the formatters make the code style worse. Eg. black really messes up
pycardium/modules/py/htmlcolor.py
.Well, I guess we can just decide to wrap blocks like these in linter-disable comments and enforce use of the formatter for all our sources.
It would still be nice if we can somehow trigger a message so a potential contributer learns how to format the sources.