New feature: "Custom MegaLinter Flavors"

[nvuillam]

We definitely need something, maybe:

• generating a base image with just the core and no linter

• use mega-linter runner to generate a template repo with a dockerfile based on the the core image

• add instructions to select the linters for your custom flavor (a .megalinter-flavor.yml file maybe ?) + how to configure the repo (variables...) to have ready to use images generated via a GitHub actions workflow

• Make sure to display in the execution log that the Flavor used in unofficial (anyone could build a hacky flavor so we have to be clear about using images we didn't generate is not MegaLinter's responsability

[nvuillam]

cc @bdovaz :)

[bdovaz]

@nvuillam I would like you to explain in detail that second step of how mega-linter runner generates a Dockerfile starting from the core image without linters to understand the flow better.

My analysis, which I don't know if it is yours or if it is different (because I need more explanation on yours), would be that mega-linter runner would run the build.py script (which has functions to generate the Dockerfile of each linters separately or each flavor) and would have a function that from a .megalinter-flavor.yml input as you say, could be instructed to generate the Dockerfile that each one wants.

The only drawback of all this is that there would not be a registry where to cache all these combinations (docker / ghcr) as until now with flavors and we would delegate that each user would have to configure and build the image.

cc @echoix

[echoix]

Is there something we can learn about how devcontainers spec use features to build a docker images with parts contributed by multiple sources?

[nvuillam]

@bdovaz the goal is to provide a default github workflow that would take care of the build & publish of the Dockerfile

About mega-linter-runner actions, i'd see it more about just copying the necessary files to generate the custom Dockerfile, including a very light version of build.py that would

• read locally defined mega-linter-flavor.yml
• get MegaLinter descriptors from the main repo, on the branch corresponding to a give MegaLinter version (so custom flavors would follow the same SEMVER than main MegaLinter app)
• generate Dockerfile based on a base image megalinter-flavor-base that we would generate and publish from main MegaLinter repo

On the user level , the path would be something like:

• Create a blank repo
• mega-linter-runner --init-custom-flavor , that init files in the repo
• Update mega-linter-flavor.yml to select the wanted linters
• Call local bash build.sh --megalinter-version v8.3.0 to update local Dockerfile
• Commit, push
• Create a GitHub Release (that would docker build & push on user own docker hub / ghcr.io account)
  • image name would be megalinter-custom-flavor- + customFlavorName (ex: megalinter-custom-flavor-Whatever )

Example: mega-linter-flavor.yml

name: Whatever
# Case where we want all linters from a descriptor
DESCRIPTORS:
- BASH 
- YAML
# Case where we want only some linters, so use linter key
LINTERS:
- GO_REVIVE
- PHP_PSALM
- PHP_PHPSTAN

Note: maybe instead of the mega-linter-runner copying file, we could create a "megaLinter-custom-flavor-template" repo, so people would just creata a new repo from it ? I was thinking about mega-linter-runner in case of later upgrades of the light build.py for example, but maybe we can"refresh" a repo from the template repo used to generate it ?