• 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:

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

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

    Edited by John Berkers
  • 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.

    Edited by Tudor Marghidanu
  • 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.

    Edited by DarwinJS
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment