Super-linter: Groovy linter not respecting linter configuration set

[Clint-Chester]

Describe the bug
Linting errors are not being identified by the Super Linter for Groovy files, but they are being identified locally with the same configuration.

To Reproduce
Steps to reproduce the behavior:

1. Set the following configuration in .github/linters/.groovylintrc.json

{
    "extends": "all",
    "rules": {
        "basic.DeadCode": "error",
        "convention.CompileStatic": {
            "severity": "info"
        },
        "convention.FieldTypeRequired": "info",
        "convention.IfStatementCouldBeTernary": "info",
        "convention.NoDef": "info",
        "convention.TrailingComma": "off",
        "convention.VariableTypeRequired": "info",
        "dry.DuplicateListLiteral": "info",
        "dry.DuplicateMapLiteral": "warning",
        "dry.DuplicateNumberLiteral": {
            "ignoreNumbers": [0, 1, 2, 3, -1],
            "severity": "info"
        },
        "dry.DuplicateStringLiteral": "info",
        "exceptions.ThrowException": "info",
        "exceptions.ThrowNullPointerException": "info",
        "exceptions.ThrowRuntimeException": "info",
        "exceptions.ThrowThrowable": "info",
        "formatting.BracesForClass": "info",
        "formatting.BracesForForLoop": "info",
        "formatting.BracesForIfElse": "info",
        "formatting.BracesForMethod": "info",
        "formatting.BracesForTryCatchFinally": "info",
        "formatting.Indentation": {
            "spacesPerIndentLevel": 4,
            "severity": "info"
        },
        "formatting.SpaceAroundMapEntryColon": "off",
        "groovyism.ExplicitCallToEqualsMethod": "info",
        "logging.Println": "off",
        "unused.UnusedArray": "error",
        "unused.UnusedObject": "error",
        "unused.UnusedPrivateField": "error",
        "unused.UnusedPrivateMethod": "error",
        "unused.UnusedPrivateMethodParameter": "error",
        "unused.UnusedVariable": "error",
        "unnecessary.UnnecessaryReturnKeyword": "off"
    }
}

1. Setup the following groovy file.

import grails.test.mixin.TestFor
import spock.lang.Specification

/**
 * See the API for {@link grails.test.mixin.services.ServiceUnitTestMixin} for usage instructions
 */
@TestFor(IntegrationService)
class IntegrationServiceSpec extends Specification {

    def setup() {
    }

    def cleanup() {
    }

    void "test something"() {
    }
}

1. Run through Super Linter in GitHub
2. Run through same linter locally

Expected behavior
Linting errors that should be produced are the following:

10    info     Class should be marked with one of @GrailsCompileStatic, @CompileStatic or @CompileDynamic  CompileStatic

  12    warning  Violation in class IntegrationServiceSpec. The method setup is both empty and not marked with @Override  EmptyMethod
  12    warning  Violation in class IntegrationServiceSpec. The method setup is public but not a test method  JUnitPublicNonTestMethod
  12    info     Method "setup" has a dynamic return type  MethodReturnTypeRequired
  12    info     def for method return type should not be used  NoDef
  15    warning  Violation in class IntegrationServiceSpec. The method cleanup is both empty and not marked with @Override  EmptyMethod
  15    warning  Violation in class IntegrationServiceSpec. The method cleanup is public but not a test method  JUnitPublicNonTestMethod
  15    info     Method "cleanup" has a dynamic return type  MethodReturnTypeRequired
  15    info     def for method return type should not be used  NoDef
  18    warning  Violation in class IntegrationServiceSpec. The method test something is both empty and not marked with @Override  EmptyMethod
  18    warning  Violation in class IntegrationServiceSpec. Test method 'test something' makes no assertions  JUnitTestMethodWithoutAssert
  20    info     Class does not end with a blank line before the closing brace  ClassEndsWithBlankLine

Actual behaviour
Following log message from Super Linter:
2020-09-10T04:04:57.1731549Z 2020-09-10 04:04:57 [INFO ] - File:[WebMethodServiceSpec.groovy] was linted with [npm-groovy-lint] successfully

[nvuillam]

mmmm strange, i'll try to have a look :) ( I maintain npm-groovy-lint )

[Clint-Chester]

@nvuillam my theory is potentially on how it's using the --files parameter. I was noticing that if you passed in the exact file names into this parameter it wouldn't run, but adding wildcards to each of the file names would make it analyse. Do you think that could be it?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[Clint-Chester]

Is there anyone else using the groovy linter experiencing the same? 😄

[nvuillam]

@Clint-Chester can you try with Mega-Linter and tell me if you have the same issue ?
It will help knowing if the problem is from npm-groovy-lint or the code calling it ^^

[Clint-Chester]

@nvuillam Mega Linter works as expected 😄 so that's a positive!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[Clint-Chester]

Checked the source code of both this Super Linter and the Mega Linter in the thread and the Mega Linter uses wildcards on the the file names where as the Super Linter is just passing the file names in without wildcards. Struggling to find the time to do a PR for it at the moment but 95% sure that's the issue 😄

[nvuillam]

Checked the source code of both this Super Linter and the Mega Linter in the thread and the Mega Linter uses wildcards on the the file names where as the Super Linter is just passing the file names in without wildcards. Struggling to find the time to do a PR for it at the moment but 95% sure that's the issue 😄

I confirm this is the issue :)
Sorry to have not made a PR here... but all my efforts are on Mega-Linter now, for a lot of reasons :)

[GaboFDC]

But just to make sure I understand correctly, running the groovy linter with exact file names is not a supported case? And this why the error happens?

[Clint-Chester]

But just to make sure I understand correctly, running the groovy linter with exact file names is not a supported case? And this why the error happens?

It's more that it is currently failing silently (i.e. saying there's no errors) when you are trying to lint groovy files based on the files changed. The groovy linter can lint exact file names if you pass each file name with wildcards on the end of the file path e.g. 'directory/filename.extension**'. Not ideal but it will at least work as expected.

[nvuillam]

for my defense... initially npm-groovy-lint was only a CodeNarc wrapper, so I just reused its arguments ...
But I agree that someday it would be nice if it could also accept a file or a list of files as final argument, like 90 of other linters :)

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.