Thanks for this. I have found, in practice, that with a later release, the LINTER_RULES_PATH needs to be set. Probably be best if the snippet is updated as follows:

superlinter:
  stage: linting
  image: github/super-linter:latest
  script: [ "true" ]
  variables: 
    RUN_LOCAL: "true"
    DEFAULT_WORKSPACE: $CI_BUILDS_DIR
    ANSIBLE_DIRECTORY: $CI_PROJECT_PATH
    LINTER_RULES_PATH: $CI_PROJECT_PATH/.github/linters

Structuring this way also makes it easier to add/remove other available variables as documented.

Why set the workspace to $CI_BUILD_DIR not to $CI_PROJECT_DIR, the latter makes more sense since some of the tools will automatically load the .*rc configuration files.

Hi @marghidanu,

A worthy suggestion. I am by no means an expert on GitLab CI, so I will have to give this a try.

@jyavorska How does this work on a self-hosted gitlab. Can anyone give me any advice? What do I need to do to make this work. What you have posted here is not everything, is it?

@feckert you need to have Docker runners registered in order to run Docker images, that's all.

CI_PROJECT_DIR would be the correct var to use.

The full path where the repository is cloned and where the job is run. If the GitLab Runner builds_dir parameter is set, this variable is set relative to the value of builds_dir. For more information, see Advanced configuration for GitLab Runner.

CI_BUILD_DIR would be scanning all projects in the build directory.

I have also put together something similar over here - it additionally demonstrates how to use it as a standardized extension in your organization (if that is desirable): https://gitlab.com/guided-explorations/ci-cd-plugin-extensions/ci-cd-plugin-extension-github-action-super-linter

This is for CI/CD, is there a way to enable it for on-recieve server hooks?

Intensive processes like this are not a good use of receive hooks. They run inside the core of GitLab server.

Generally it is better to use CI for extensive checks and the merge request as a form of code quality checking:

• Have branch protections on the branches where you want clean commits.
• Have CI run on feature branches and the submitter can clean up their code (and collaborate on it).
• Then when they merge to the shared branch they can "Squash Commits" in the GitLab Merge request and the commits will be nice and clean for that branch.
• GitLab code quality plug-ins also report to the MR. Here is an example of adapting Flake8 to report to GitLab's normal Code Quality MR widget: https://gitlab.com/dsanoy-demo/python/flask_autodevops/-/blob/master/.gitlab-ci.yml#L11-17

Not happy with that answer and I do believe it would be fine to use it as a receive hook, I am doing CI/CD and I will use this there too, as a safety measure, but I would like to prevent it from getting into the repository in the first place, if I detect it during my pipeline it's already too late.

@mfaine - if you are running your own hosted GitLab you can create custom server hooks and run whatever you like as documented here: https://docs.gitlab.com/ee/administration/server_hooks.html

The reasons I gave before, as well as the following, are why customers cannot run arbitrary code for pre-receive hooks on GitLab.com SaaS hosting:

• You can't run containers inside GitLab server - so you will need to install any Checkov dependencies onto the GitLab server itself. If you allow other prereceive hooks to do likewise, you eventually end up with many other dependencies installed.
• The addition of runtimes and custom code can complicate upgrades of GitLab when trying to keep compatibility with all the dependencies of pre-receive hooks and the hook code itself. If you don't already have a second "integration" instance of GitLab to test upgrades on - having a lot of prereceive hook dependencies would be a reason to add that to the upgrade procedures for GitLab.
• Prereceive hooks completely block the pushing of code to the central, backed up repository - so they become a first class operational problem if they don't function perfectly all the time. Malfunctioning CI does not cause the same level of concern.
• CI Checks are selectable and customizable by project and branch and any conditional logic that can be insertered in pipelines. Pre-receive hooks can be configured per-project (on or off), but global pre-receive hooks cannot be disabled for exceptions on a per-project basis and per-project ones require server configuration for every project that wants to include them.
• CI configured checks can be pegged to different versions of the checking software for each project or branch or pipeline criteria (e.g. different versions of Checkov), server based hooks are the same version for the same project or entire server (depending on how they are installed)

It's really a general principal of separation of server roles (and dependencies) for the sake of stack simplicity and for the sake of deploying only what has been tested together.

Hello, a Gitlab version of super linter is available in the r2devops hub

It brings also test report integration in Gitlab MR widgets (using JUnit)

Oh @thomasboni - nice work around to get a proper artifact file!

Thanks @DarwinJS 🙏 We encourage r2devops hub contributors to provides jobs well integrated in Gitlab, mainly by converting their output to be compatible with a Gitlab report.

You can take a look at r2devops.io/jobs to find another great jobs 🙂

You can easily integrate MegaLinter on GitLab CI, for more capabilities and better performances ;)

https://nvuillam.github.io/mega-linter/mega-linter-vs-super-linter/

# Mega-Linter GitLab CI job configuration file
# More info at https://nvuillam.github.io/mega-linter
mega-linter:
  stage: test
  # You can override Mega-Linter flavor used to have faster performances
  # More info at https://nvuillam.github.io/mega-linter/flavors/
  image: nvuillam/mega-linter-python:v4
  script: [ "true" ]
  variables:
    # All available variables are described in documentation
    # https://nvuillam.github.io/mega-linter/configuration/
    DEFAULT_WORKSPACE: $CI_PROJECT_DIR
    DEFAULT_BRANCH: master
    # ADD YOUR CUSTOM ENV VARIABLES HERE TO OVERRIDE VALUES OF .mega-linter.yml AT THE ROOT OF YOUR REPOSITORY
  artifacts:
    when: always
    paths:
      - report
    expire_in: 1 week

@nvuillam - nice! I put in a couple issues to their project:

• Support for JUNIT artifacts for results visualization
• Support for GitLab "Code Quality" artifacts

copy: @mlebeau

Hey @DarwinJS, a plug & play job is available for JUnit visualization, it parses all linters logs. You can find it here, all you have to include in your pipeline is the following piece of code:

include:
  - remote: 'https://jobs.r2devops.io/latest/mega_linter.yml'

And if you need to use a specific flavor, you can add this in your .gitlab-ci.yml

  # Replace FLAVOR by the flavor you need 
  image:
    name: nvuillam/mega-linter-FLAVOR:v4
    entrypoint: [""]

I hope this can help you in your projects!