Super-linter: Split up checks into smaller checks for each linter

[admiralAwkbar]

Currently, this runs as 1 giant check. And that is great except for larger repos will have a very large file to parse. We can utilize the checks API and make each linter its own check and make this sooo much nicer to look at.

Example:

• Source-Linter
  
  
  
  • bash linter
  
  
  • ruby linter
  
  
  • etc...
  
  

At the end of the Action you will see many smaller jobs inside the main job

[Hanse00]

Hi @admiralAwkbar, are you actively working on this? If not, it seems like an excellent opportunity to learn more about using GitHub Actions, and I'd like to give it a try.

[admiralAwkbar]

@Hanse00 Hey! it was a great idea when this was first being developed.

At this point, I have not had the time to make it happen, but would love some help :)
Let me know if I can be of any help

thanks!

[Hanse00]

We all know how that goes :)

I'll get my environment set up, and poke around at it today.

[Hanse00]

@admiralAwkbar Just want to check my assumption here: Since I am modifying the scripts that make up the action, rather than following your instructions on running the linter locally, I should build a new version of the container and run the action locally, is that correct?

You mentioned using "checks" in your original description of the issue. Having dug a little deeper. It looks to me like the natural path here is to use multiple "jobs" inside the GH Actions "workflow" to achieve each linter being its own process. Not literally trying to code in use of the Checks API directly. Have I got that right?

[admiralAwkbar]

@Hanse00 You are correct, sorry for the incorrect language on it :)
your assumption is correct

[Hanse00]

Not a problem at all! Just wanted to confirm we're in agreement.

[Hanse00]

After further investigation, this is what I've concluded:

• For each "check" to be reported upon separately in the UI as you're suggesting. They need to be separate "actions" within a "workflow".
• GitHub only supports publishing "actions" on the marketplace, not whole "workflows", so we cannot publish a full workflow that will run all the individual checks for us on the marketplace.
• There are a set of "starter workflows" that GitHub makes available. These are managed via the https://github.com/actions/starter-workflows repository. The only way I see for us to publish a full workflow, is by having it included there.

Whether Github thinks a workflow like this should be included in the starter workflows, is out of my hands. I could go open an issue there to find out. But perhaps you have a better way internally of working out if that's what the company wants to do?

If we proceed down that path, we need to write a workflow that uses individual actions for each of the linter functions. This means the action needs to support selecting which linter(s) to run in an individual action.

I see you've laid some groundwork by supporting environment variables for linter selection, however they all currently default to on.

This means that each action would need to disable all but one linter, to get the desired behavior.
It also means we need to be careful when adding new linters down the line, as these new linters will default to on, unless people know they've been added, and turn them off.

For those reasons, I propose a change in the behavior:

If none of the linter selection variables are present, default to all being enabled. This will give a good "out of the box" experience for those that don't want to play with the variables.
However if any of the variables are present, only enable the linters those variables indicate (That is, default to off, use variables to enable).

With that done, we can add inputs to the action, that will accept parameters for which of the linters to trigger in a specific run of the action.

There may of course be something I am missing, but that looks to be the deal to me @admiralAwkbar

[admiralAwkbar]

@Hanse00 it would appear that this would require a little bit of re-arch the scripting and how variables are being passed and such...
I see it as a small win, but at this point, I don't have the time to make a change of that magnitude.
We're still working on getting additional adoption of the tooling, and then I would assume the bug fixes that follow :)

Thank you so much for digging into this and addressing all the issues that would need to be overcome.

[Hanse00]

Not a problem! It's always good to get an understanding of the problem, before jumping in :)

That being said, are you open to the community potentially working on the variable passing? Or it is something you'd rather take ownership of for now?

It's totally understandable if you want to keep this close, this early on in the lifecycle of the project. If however you do decide you want help with this, I think the next step would be to create a separate issue, where we can hash out how we want the variable parsing to work.

[admiralAwkbar]

@Hanse00 I would be open for all the help :)
I agree i think this is more of an epic, and would need to open smaller issues to track the underlying changes to make this work in the real world

[Hanse00]

So now that we are able to run the linter for each language relatively easily, perhaps it's time to revisit this?

As before, my understanding is still that we can lay the groundwork, but at the end of the day, a workflow would need to be written for this, rather than it being written directly into the action.

[zkoppert]

Hey @Hanse00, I'm starting to notice several other requests coming in that are blocked without having something like that this issue describes. What are your thoughts on what this could look like?

[Hanse00]

Hey! Sorry, the day job has been keeping me quite busy lately 😄 Let me try to find some time this weekend to dedicate towards this. @zkoppert

[zkoppert]

No problem. I think this is going to be one of the defining features of v4.0. Really appreciate you working on it!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.