oxsecurity / megalinter

🦙 MegaLinter analyzes 50 languages, 22 formats, 21 tooling formats, excessive copy-pastes, spelling mistakes and security issues in your repository sources with a GitHub Action, other CI tools or locally.
https://megalinter.io
GNU Affero General Public License v3.0
1.89k stars 232 forks source link

Doesn't seem to use LINTER_RULES_PATH in WSL #3574

Closed michaeloa closed 2 months ago

michaeloa commented 4 months ago

Describe the bug The megalinter does not seem to respect the LINTER_RULES_PATH in the megalint config.

To Reproduce Add LINTER_RULES_PATH in the configuration file.

  1. Place .cspell.json in LINTER_RULES_PATH
  2. Run lint
  3. Add a misspelled word caught by lint to .cspell jon
  4. Run lint

Expected behavior The linter should no longer flag the misspelled word.

I can move the exact same .cspell.json to the local repository, and it works as expected. So the problem is not in the config gile.

I would also like to use $HOME to set the path, but that does not seem to work either.

michaeloa commented 4 months ago

So, I'm finding that this works if I set the LINTER_RULES_PATH to an URL, but not if it is set to a file path.

I'm guessing that this is being appended to some path without it being obvious. Just to describe the use-case: I would like to have projects include a megalint config that points to a folder on the current local users disk, e.g., $HOME/.local/linters or similar. However, this currently does not work at all.

nvuillam commented 4 months ago

@michaeloa please could you share your .mega-linter.yml config file ?

michaeloa commented 4 months ago

HI. Our lint config is OSS; you can find it here: https://github.com/elhub/devxp-lint-configuration

I assume you want to see an example of file referemce, though; see the "file-reference" branch: https://github.com/elhub/devxp-lint-configuration/tree/file-reference

Run "make test".

Now the interesting thing I found as I created this example, is that this particular variant (where I refer to ./resources/ in https://github.com/elhub/devxp-lint-configuration/blob/6a49ff25dc674542e2d9530bf6434c88fc848fb3/resources/.mega-linter.yml#L7) works.

If I change that line "/home//workspace/git/devxp-lint-configuration/resources/" which is the absolute path of the directory, it fails...

github-actions[bot] commented 3 months ago

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.

michaeloa commented 2 months ago

This does seem like a bug to me.

nvuillam commented 2 months ago

@michaeloa LINTER_RULES_PATH can get a path:

It can not use $HOME or folder that are parent to the analyzed repository

        if config.exists(self.request_id, "LINTER_RULES_PATH"):
            linter_rules_path_val = config.get(self.request_id, "LINTER_RULES_PATH")
            if linter_rules_path_val.startswith("http"):
                self.linter_rules_path = linter_rules_path_val
            else:
                self.linter_rules_path = (
                    self.github_workspace + os.path.sep + linter_rules_path_val
                )
michaeloa commented 2 months ago

Ah - so basically only relative paths? In that case, I would suggest adding that to the documentation in https://megalinter.io/latest/config-variables/

Thanks for the clarification.

nvuillam commented 2 months ago

@michaeloa we assumed that config files are within the analyzed repository , which is the common practice , or exposed via HTTP in case of shared config

It would be technically possible to allow absolute path but.... is there really a use case ?

michaeloa commented 2 months ago

Don't know what others do, but for the use-case we are coming from, it worked very well. We had a different linter setup (though current plan is to switch to megalinter). We have a common setup script for all of our dev boxes (running WSL) in order to simplify and easy onboarding and maintenance, which installs/upgrades relevant developer software and also installs standard files, templates, plugins, etc. That includes/included lint configuration files (and linters).

The advantage of this (in the way we used it, at least) is that you don't need the lint config files in each repository since they are sourced locally from a common directory. I'd prefer that to the way megalinter currently handles this with HTTP shared config, since megalinter (at least how its working for us right now) downloads the file to the local repo as root/root which I feel is rather messy and inconvenient (people running the linter wonder why there is suddenly 12+ new files in their repository, if they have not set up gitignore properly).

nvuillam commented 2 months ago

I get your point, that's a uncommon use of MegaLinter (which is usually scoped by repo as root folder)

But why not, as such behavior would happen only if you force a value in LINTER_RULES_PATH (but I can't promise that all linters will act correctly with config files at upper level than the root analyzed folder)

PR on the way :)