Please, can we bless HLint GitHub action

[Anton-Latukha]

In Open Source projects, the main CI pass for HLint is Haskell-CI.

Rarely do I see HLint configured in the projects CI, especially as a separate workflow.

The main path I see CIs use HLint is through Haskell-CI autogeneration.

The Haskell-CI autogeneration has a problem - it generates only 1 workflow. And that workflow installs & runs HLint in a manual way internally inside the workflow. That is a primitive approach that:

has severe limitations

1. Workflow gets forked into builds through internal build matrix. So ci.yml runs N, in big projects - ~10 times, for example for every GHC-version x platform. And that means for every of 10 builds - the HLint set up is downloaded & run & then run HLint runs 10 times per commit push.

2. As recently in HLS - the CI stops all-together for all PRs, because build nodes spamming the same actions (as there ~10 times per commit push) - some service metric quotas somewhere are hit & providers block further requests - which blocks all CI builds for everybody in the project. On quotas - Travis & Docker Hub & Nix installation had networking disconnects & addresses unreachable, GitHub & Hackage & free-provided CDNs are also - no different, quotas are hit from time to time during proactive development, & I think we must preserve the free lunch for projects & the bandwidth of Hackage & especially when doing that is more robust & effective.

3. Additionally - afaik Haskell-CI currently does not expose the HLint suggestions into the interface of a PR review process - so HLint runs are disjointed from review processes. Either HLint silently suggests stuff inside the build logs with green status, or can gets configured to throw exit code & aborts the whole build/CI workflow because of 1 code suggestion, it is "either" - because GitHub CI provides only 2 build states - green or red - there is no orange/yellow-middle states or optional checks in it.

---

The proper way of providing the HLint into CI - would be suiting of HLint setup for particular CIs.
Currently, there is no official way of providing HLint into GitHub CI, - except for curl -sSL https://raw.github.com/ndmitchell/hlint/master/misc/run.sh | sh -s . - which has the exact effects described above.

Other ways of using HLint in GitHub CI are not known. There are 3 automations/"actions":

• ndmitchell/neil

  hlint/.github/workflows/ci.yml

  Line 38 in 918d3b9

  - uses: ndmitchell/neil@master

  - which is not documented & unpublished GitHub action. So users can't know of its existence. idk if it has GitHub review integration?
• https://github.com/marketplace/actions/haskell-linter - a Docker version of a CI automation.
• https://github.com/rwe/actions-hlint-run - a JS version (JS way of doing GitHub Actions is the most effective one, because of the GitHub CI proprietary reasons).

The last two have project patch review integration, so CI provides information in patch review:

^ I gradually discourage usage of concrete [] type for singletons in the HNix project, so the migrations of the codebase to the proper container types for stuff would be easier.

But both of those automations are pretty dormant projects & unofficial ones. It is hard to automate Haskell-CI for every particular platform, but if the platform has standard automations for CI workflows - it can be automated easily:
Haskell-CI would only need to create a separate file as simple as this workflow, and HLint is cached over all runs, & it would run once per git push & provide patch review information.

---

Plans upon plans:

1. I'd wanted to review those HLint actions.
2. And introduce them or an improved variant (they are BSDv3 & MIT licensed) into https://github.com/haskell/actions.
3. Then Haskell-CI can standardize on that action for GitHub.
   ...
4. Result:

it gets easier for `Haskell-CI` to maintain the GitHub automation, all GitHub Haskell projects get faster & nonblocking HLint automation that helps contributors & maintainers with review information, as new shiny easy automation it which gets picked-up by maintainers - the quality of code improves, the coding styles improve:

---

Of course, everyone tunes HLint to the project, we just try to provide an easy time for us & everyone with it.

What do the project authors think about this?

[Anton-Latukha]

& I promise to provide continuous support to the GitHub Action chosen/made & would communicate/work on integrating it into hackage-ci.

[ndmitchell]

Sounds like a great idea! My preference would be to work with whichever existing HLint action is the "best" and get that into Haskell-CI, rather than forking and creating something anew.

[Anton-Latukha]

Yes - I agree.

[Anton-Latukha]

@rwe, what would you say about it?

[rwe]

Well, I'd be tickled if anyone finds those useful. (The one in @Anton-Latukha's screenshot is mine, based on the presence of that silly field separator in the message 😊).

I created https://github.com/rwe/actions-hlint-setup and https://github.com/rwe/actions-hlint-run primarily as an exercise to gain familiarity with GitHub Actions' capabilities. They were integrated initially over into the https://github.com/agda/agda repository, but I haven't advertised them at all.

And although they haven't been updated in about a year—so maybe there are better ways of doing things now?—it's pretty dirt simple and so probably an ok place to start.

As you noted, they're already MIT-licensed and so free to use. Let me know how I can help.

[Anton-Latukha]

Your action works nicely in HNix for some time. I searched the Internet for HLint automation & your action was the best thing.

I have some skin in the game - implemented several GitHub actions myself, for example "composite type" action & a Docker action, but so far not done it in JS way - that is one of "why" I am interested to participate in this.

About types of actions:

All that is officially said in the difference between them is: https://docs.github.com/en/actions/creating-actions/about-custom-actions & Internet is not healful to analyze what type is most suitable.
Was looking couple a of weeks ago at GitHub Actions docs & implementation possibilities. From all available through docs is seen they still advertise the old initial JS app way as it still wins in many terms - they seem to run it in some light environment & faster startup time & cache & infrastructure integrations are well-developed for it. Composite actions have a strong security question for them. For example, & Docker action needs to load the image every time & layers & so on. The Docker action is the most flexible long-term & the easiest to develop & maintain, but has a start-up time. Composite action is a complex middle ground, it allows for action to embed other actions - but that feature is not needed when one thinks about automation through contributing to Hakell-CI. And just biting the bullet and maintaining the JS app - is what GitHub sort of expects & what haskell/actions uses.

---

[Anton-Latukha]

I understood that HLS support of HLint - of course has much more important, but GitHub support also has an important sides to it in maintaining the public projects

HLS guys already did the main work. - HLS loads HLint & people should project recommendations during contributions to projects.

But I know a lot of people who turn off linting fully & ... say bad things about it. From a person that written a book on Haskell & understands something about Haskell design - almost all (& hidden ones) HLint rules I find useful, for me not use HLint suggestions is ... strange approach. But that those people turn off HLint does not mean that the project maintainers do not have right to maintain projects - they separately have own rights & responsibility to control the quality of code. Linting at least reduces the code that is redundant & simplifies it. From my point of view - HLint rules also teach. Especially important thing is that Action is making a soft suggestions to people - which is a subtle detail that in a Wu-Wei manner, as HLS HLint automation also produces huge results for ecosystem. CI HLint done in proper way (& we can supply those defaults) doesn't guards the process, & maintainer does not need to ask the contributor to turn on the linter & force to do something (the art of PR process is how to not force people, while also receive enough to have a good main project state) - the contributor sees the lining suggestions & decides to do something without maintainer involvement, or ignores the suggestions, & maintainer sees the review suggestions & decides on its own - the softness of this process is precisely the strength of management results of it.

I want to spread the HLint use & so people contribute a lot of different kinds of suggestions to it.

---

[Anton-Latukha]

Thank you every for participating in this.

Our dialog produced fruits.

Process is moved further upstream, so scope of the process now there ⬆️.

[ndmitchell]

Sounds like it would be useful to add a short section in the readme, perhaps under https://github.com/ndmitchell/hlint#running-with-continuous-integration, that says what the recommended HLint is?

[Anton-Latukha]

Good idea.

Currently, action is stuck in merge limbo for some time. I try to further the agenda & waiting until somebody comes around to work with me on the merging process there.

[Profpatsch]

FYI, I created a little jq script which can format hlint --json output into the log format expected by Github Actions:

https://gist.github.com/Profpatsch/9af96a9773fe18825221eb55b4f4fbd5

[ndmitchell]

Thanks @Profpatsch. Should that be an output format produced by hlint natively - e.g. hlint --github? @Anton-Latukha, would that transformation being inside HLint help with the github action?