Separate relative path mode for config vs output

[nvx]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.
• I agree to follow this project's Code of Conduct

How did you install golangci-lint?

Official GitHub Action

Your feature request related to a problem? Please describe

Specifying a relative path mode of cfg is needed to reliably detect additional config files such as for ruleguard.

Unfortunately this then results in linter outputs using paths relative to the cfg directory too so they start with eg ../../../../../../ breaking CI workflows from referencing the right file

Describe the solution you'd like

A way to specify ruleguard configuration relative to the config directory but path outputs relative to either the working directory, gitroot, or go mod root would fix the issue.

Describe alternatives you've considered

This seemed to work fine under golangci-lint 1.x. Specifying gitroot as the relative-path-mode breaks loading ruleguard rules but output paths are fine, specifying cfg allows ruleguard rules to load fine but output paths are wrong.

Additional context

ruleguard config:

        ruleguard:
          failOn: all
          rules: ${base-path}/ruleguard/*.go

Supporter

• I am a sponsor through GitHub or OpenCollective

[ldez]

Hello,
can you provide a reproducible example?

[nvx]

Hello, can you provide a reproducible example?

I've made a contrived example that demonstrates the issue, you can see the workflow run here with the output paths for a file main.go in the root of the repo instead showing up as ../main.go: https://github.com/nvx/golangci-lint-issue-5646/actions/runs/14119963047

Clicking the link ../main.go L6 results in a 404 page at https://github.com/nvx/golangci-lint-issue-5646/blob/main.go#L6 when the correct path would have been https://github.com/nvx/golangci-lint-issue-5646/blob/main/main.go#L6 if it wasn't for the ../ removing the branch name (in this case main). It also breaks other views where it would normally show the linter outputs alongside the diff etc.

I say contrived example as I'm normally using a reusable action with the config file and rules inside the reusable action repo so normally the path would be the relative path between where the reusable action is checked out and the workspace where the code is checked out leading to a much more complex relative path than just a single ../

[ldez]

Why do you not use the other modes?

Specifying gitroot as the relative-path-mode breaks loading ruleguard rules but output paths are fine

Do you have a reproducible example of this behavior?

[ldez]

I was tricked by the cache.

[nvx]

Why do you not use the other modes?

Specifying gitroot as the relative-path-mode breaks loading ruleguard rules but output paths are fine

Do you have a reproducible example of this behavior?

When trying gitroot with a reusable workflow it failed attempting to load the ruleguard files from the path relative to the gitroot, but in my simple example all in one repo it seems to work. I'm not sure why there is a difference, will try splitting out the action like I have in my real repo and see if I can reproduce it there

[ldez]

The v1 was working only because the report paths where relative to wd.

[nvx]

Just to confirm though, is ${base-path} in the config file meant to be relative to the config file always, or relative to the path defined in relative-path-mode config option? Because in the repo as stands it's showing as relative to the config file which seems counter to what the documentation says it should be (and counter to my experience when the config file was in a reusable action repo)

[ldez]

relative to the path obtained by the relative-path-mode config option

[ldez]

I know your example is contrived but something like that works:

version: "2"
run:
  relative-path-mode: gitroot

linters:
  enable:
    - gocritic
  settings:
    gocritic:
      enabled-checks:
        - ruleguard
      settings:
        ruleguard:
          failOn: all
          rules: ${base-path}/linter-config/ruleguard/*.go

[ldez]

I introduced the modes like gitroot and gomod for this kind of context.
I don't want to come back to the previous hell paths inconsistency.

So, can you say if my previous example works for your real context?

[nvx]

I introduced the modes like gitroot and gomod for this kind of context. I don't want to come back to the previous hell paths inconsistency.

That would work in that contrived example, although the issue is the real world example the linter-config directory is not housed under the gitroot or gomod as it's in an entirely separate path as housed in a reusable action

For example the config file would be at:
/home/runner/work/_actions/orgname/actions-repo-name/main/golang/lint/golangci.yml
But the workspace where the git repo is checked out and go.mod file exists would be at:
/home/runner/work/reponame/reponame

Having ${config-path} that always points to the directory the config file is in ignoring the relative-path-mode option would work as relative-path-mode could be gomod or gitroot for sane linter file output paths while still enabling locating rules relative to the linter config file.

[ldez]

I don't think that ${config-path} is the right approach because it will reintroduce path matching inconsistency, and I don't want that.

I have another idea.

For me, the problem is not related to paths inside the configuration but to the paths of the reports.

I differentiate "matching paths" and "user-facing paths".

[ldez]

I have a question: are you defining exclusion paths or rules (not nolint directives)?

The cfg mode will not work in your context because the paths should be related to the configuration file, and based on your explanation, it is not possible.

The wd mode will partially work for the exclusions matching: you will not be able to run golangci-lint inside a package, because the paths will not match. And it will not work for ruleguard rule paths.

The gitroot and gomod modes will work for the exclusions matching, but they will not work with ruleguard because you cannot define the ruleguard rule paths (still based on your explanation).

So, I guess you are not using exclusion paths or rules.

[nvx]

I have a question: are you defining exclusion paths or rules (not nolint directives)?

I am actually, but only path: _test\.go where I want specific rules to be disabled in unit tests. I imagine since I'm not matching on the full path just the suffix (thinking about it I probably should have a $ at the end of that) the path doesn't matter

The gitroot and gomod modes will work for the exclusions matching, but they will not work with ruleguard because you cannot define the ruleguard rule paths (still based on your explanation).

Yeah, hence allowing a separate variable to be used in things like ruleguard ruleset paths that always points to the config path was my idea of a solution. I agree using the config file path for anything other than config (eg exclusion paths) would be super confusing though, so maybe if a ${config-path} option was added preventing it from being used for code related path fields (like exclude paths) and only allowing it in config related fields like ruleguard.rules would be the ideal solution.