hlint workflow

We have recently started using hlint in our CI infrastructure. This is a good thing, as it means we can slowly work toward perfection in the style of our codebase.

However, I have been frustrated a number of times recently with the way the CI workflow works, where I push a linting bug, only to learn quite a while later that I have a linting error. I learn quite a while later not necessarily because the CI takes very long, but that I have task-switched away. And then, when I'm ready to task-switch back to a particular ticket, expecting fresh informative CI results, I see the lint error. This means I can't do the more interesting work I had intended to do in that time-block.

I have two possible suggestions for remediation of this problem:

• Do lint checks right during the commit. That is, GitLab can refuse my push if there are any linting problems. This will give me quick feedback so I can fix my error and push again. Key detail: the check is blocking, forcing me to see it right away (that is, it's not delivered in email, which I might ignore for days).
• Do lint checks in parallel with full validation. Then, when I come back to a patch, I see both the lint errors and the more interesting testsuite failures and can fix both at the same time.

A third, less desirable (for me) possibility is to try hard to lint locally before pushing -- much like I compile locally before pushing. But this seems like an easy step to forget.

How do others deal with the current setup? If I'm alone in wanting change here, I can change myself (I think). If I'm not alone, then changing CI centrally would seem to benefit more people.

Thanks!