Why are only some linters pinned on a given megalinter release?

[cpotteck]

To give some context, we build images based on given Megalinter release's source (not the docker image) to use on our CI.

This has generally worked very well for us, and we are currently basing our image on the megalinter v7.9.0 release. However, we recently had to rebuild the image (without updating the base megalinter version) to try and make it work with golang 1.22 and then ran into this markdown-link-check issue which appeared as a regression in markdown-link-check 3.12.0.

According to the megalinter releases, markdown-link-check was updated from 3.11.2 to 3.12.1 in v7.11.0, however as noted above we have not updated the megalinter base, only rebuilt the image. This lead me to dig a little in the main Dockerfile and I noticed that some linters have pinned versions, though most don't. This was unexpected to me as the release notes are written as if a given release of megalinter will include upgrades to specific versions of linters whereas that is not always accurate (it might be accurate for a given image tag at https://hub.docker.com/r/oxsecurity/megalinter, but not necessarily when it comes to the source code release assets on GitHub).

Some questions relating to this:

• What influences the decision behind pinning some linters but not others in the Dockerfile?
• What would be the preferred way to pin linter versions other than using the released Docker image as base rather than the source directly? We can see that it could be possible to specify versions in the descriptors themselves though we are hoping to find a more maintainable way to do this

[nvuillam]

@cpotteck maintainers and contributors of linters are very active and often release many versions :)
We are a small maintenance team so... the reason to not pin versions is ... laziness: we like to focus our efforts on tasks with added value !

Everyday, there is an automated job building again the docker image, and if it detects new versions, it generates a Pull Request that we manually validate after checking (example: #3523)

The linters who have pinned versions are either downgraded, either for some reason we did not find a way to use "latest".
For those ones, either:

• dependabot notifies us
• from time to time we make a big check to see what is upgradable (example: Cleaning of CVE exceptions + manual upgrades (Java 21, PMD7, Powershell) #3518 )
• contributors post an issue

If you really want to pin linter versions, you could submit a PR that refactors descriptors to variabilizes versions into ARG values (with default: latest) , and you could override the ones you want by sending parameters to docker build.

Out of curiosity, what are you building over MegaLinter Dockerfiles ? :)

[echoix]

Speaking of release cadence, some of them (I have one in mind) release multiple times per day...

[nvuillam]

Hello checkov 🤣

[cpotteck]

@nvuillam Thank you for the rapid and thorough response!

I appreciate the details regarding the linter dependency management process for megalinter, it definitely gives me a better understanding of the steps involved and what to expect.

RE: what are you building over MegaLinter Dockerfiles ?

Essentially building a leaner Flavor of megalinter image which applies specifically to our codebase and which we can update quickly when we would like to add/remove linters and support for a given language. It would be hard to compare it directly to one of the available Megalinter flavors because its a mix of a few, and we decided to go with a lean generic flavor rather than a dedicated flavor for different types of repositories. It would probably be possible to achieve this using the Docker images as base though we went the way of using the source and picking and choosing from there.

[echoix]

That is a long term improvement I'd like to see happening too! I've always wanted to be able to rebuild a specific image version at a later point in time.

Originally, it has been a limitation of the tools we had available to make the upgrades of each linter in a manageable way. That meant that most (if not all) installed software have no pinned version, but the custom auto update workflow runs each day and collects the versions and generates the docs for it.

Dependabot isn't really an option here, since the Dockerfiles result from the descriptors that describe the linters, how to install them, and how to use them, not a file of a specific package manager.

Now, I think it might be possible to have a better solution with renovate. Recently I learned that it is possible to define a custom manager, that can use regex to find the information to keep up to date, with the existing data sources. https://docs.renovatebot.com/modules/manager/regex/

It might be a big job, but at least with this, it would be possible to update the source files (and the resulting files) in one pass, instead of having updates of the resulting files and having to go back and apply manually the change in the descriptor and rebuild.

Of course we'd be glad to have a PR for this, even to test out a single installation type. (Maybe docker would be the easiest?)

I don't mind if it requires adding autogenerated markers in the Dockerfiles or other to help out map the result back to the source. The solution could also only update the versions in the descriptors, and the auto-update job only to keep the results file in sync.

Do you imagine something more robust for this? It simply needs to stay manageable in terms of maintenance time.

[cpotteck]

Thanks for the hints and suggestions on this! Dockerfile ARG was also my first thought as that is the part of the Megalinter source that I've had the closest look at while looking into linter versions (and it would be a solution that would work for us), but I can understand how it wouldn't be viable for all use cases.

I'll have to look at the context around descriptors and the build automation you linked above to get a deeper understanding and see if/how I can contribute to this.

[echoix]

Renovate won't update the descriptors :/

That's where the custom manager with regexes come into play. Essentially defining how to handle our descriptor format as a format it understands and can apply its rules. (They use the concepts of datasources and managers)

[cpotteck]

Just to make sure I understand the suggested solution,

• Descriptors are updated to support setting a linter version via a Dockerfile ARG
• Renovate is configured to track linter upstreams and update versions in descriptors (and in linter-versions.json?)
• Building an image with specific versions of linters would mean changing the versions in the descriptor, or passing new ARG values to docker build

I can see the concern brought up by @echoix regarding default ARG values, what would they be (latest, stable, etc.)?

[cpotteck]

@echoix for the following:

Why I think going the renovate might be easier, is that it wouldn't be needed to rebuild the Dockerfiles from PRs (since it would be updated correctly), and the PR could be tested by building it in one go.

Do you mean that Dockerfiles won't need to be changed because linter versions will be passed via ARGs, and that the tests would therefore only require building the images rather than first generating the Dockerfile, then building the images? I still need to get more familiar with your automation to fully grasp this 😅

[nvuillam]

I made the first step in https://github.com/oxsecurity/megalinter/pull/3528/files

Now if an ARG is used in a FROM installation instruction, it is set by build.py on top of Dockerfiles :)

Working example with editorconfig-checker:

• descriptor:

  megalinter/megalinter/descriptors/editorconfig.megalinter-descriptor.yml

  Line 27 in ac6bf96

  dockerfile:

• dockerfile: https://github.com/oxsecurity/megalinter/blob/main/linters/editorconfig_editorconfig_checker/Dockerfile