Skip to content
Snippets Groups Projects

ci: implement lint & Annoyatron

Merged q3k requested to merge q3k/firmware:q3k/ci-lint into master

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
Edited by q3k

Merge request reports

Merge request pipeline #1583 passed

Merge request pipeline passed for 8ef77cdb

Approval is optional

Merged by rahixrahix 5 years ago (Jul 29, 2019 5:29am UTC)

Merge details

  • Changes merged into master with 8ef77cdb.
  • Did not delete the source branch.

Pipeline #1584 passed

Pipeline passed for 8ef77cdb on master

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • 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:

    1. Limit the check (git diff) to files in epicardium/, pycardium/, and bootloader/. Maybe add lib/card10/ as well.
    2. 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 ...
  • While we're at it I could also integrate black for python formatting into the tool?

  • Author Guest

    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.

  • q3k added 1 commit

    added 1 commit

    Compare with previous version

  • 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.

  • q3k added 1 commit

    added 1 commit

    • 4418749b - ci: remote card10 remote if present

    Compare with previous version

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading