Super-linter: Keep dependencies up to date

[zkoppert]

How can we automate this project staying up to date with the latest stable version of the linters it references?

Minimally cool: Alert or issue created every time we need to update a version of a linter
Maximally cool: Automatically open a PR to rev the version once a stable release from a linter is available

[GaboFDC]

Of the top of my mind, I think a middle ground between both would be leverage dependabot in some way.

Something strange but that may work would be, putting the package file, for the dependencies we have, i.e: Gemfile for the gems we install, pipfile/requirements.txt for the python packages, package.json for js, etc. This way dependabot would detect the update and create PRs for them. The config on details for the PRs created this way can be configured via .github/dependabot.yml. And on the Dockerfile, we could change to do bundle install npm install and so on.

As I said is kind of weird, but could leverage most of the dependencies. For the ones we install via direct URL or another way, will still need manual intervention, but those will be special cases anyways.-

WDYT?

[zkoppert]

☝🏻 I think that is a great idea!

[GaboFDC]

I'm willing to give this a shot. Just a question before I start, should all be one change?
Or should I split it into Change to use package files and then setup dependabot?

[zkoppert]

I think it could all be one pull request. Thanks for taking this on! Let me know if I can give any support along the way.

[nemchik]

Just a consideration, for any tool that maintains their own docker image you can use their image as a build stage in the docker image in this repo and copy the binaries you need from their image. An example of this would be shellcheck.

[GaboFDC]

@nemchik can you detail a bit more about how this copy from another docker image would work? I'm not quite sure I'm following your idea

[nemchik]

Here is an example:
You create a build stage like this
https://github.com/linuxserver/docker-taisun/blob/ff8385e7f5cb07a7c3b07e400afd0c5fc1956515/Dockerfile#L1
You can name it whatever you want. Then you copy things from the build stage into a subsequent build stage or your final image https://github.com/linuxserver/docker-taisun/blob/ff8385e7f5cb07a7c3b07e400afd0c5fc1956515/Dockerfile#L106

This keeps your final image small, but you can effectively stage and make a mess in prior stages and only copy what's truly needed to the final image.

So we could for example setup a FROM using the image for shellcheck and then copy the binary from that build stage. The main reason to do any of this is allowing dependabot to update the dockerfile for the build stage (the FROM line).

[GaboFDC]

Thanks, will also use this options for any tools that have its own docker image.

[nemchik]

A key thing to remember is this method is probably only useful if you are able to copy a single binary or small set of easily identifiable files. I would not use it for something that gets installed via pip or npm for example (the dependencies involved there are pretty heavy, and dependabot can keep pip and npm deps up to date in this repo anyway). Shellcheck is a perfect example of a binary that can just be copied from a docker image, and luckily @koalaman is amazing and maintains versioned tags https://hub.docker.com/r/koalaman/shellcheck/tags on his docker image.

There's also two issues in his repo https://github.com/koalaman/shellcheck/issues/1492 and https://github.com/koalaman/shellcheck/issues/1943 asking for him to setup a github action for shellcheck (seems like he was on the waitlist for the beta at the time). This repo could potentially replace the need for him to maintain his own github action.