Open wesley-dean-flexion opened 8 months ago
nevermind... I found another approach that'll work. Apologies for wasting your time.
Would you mind sharing the approach here as future reference?
@echoix Sure! I Read The Funny Manual and noticed two ways to get from here to there:
Linters have *_DISABLE_ERRORS
configuration options. So, for example, if we didn't want Black or Pylint blocking deployments (i.e., if we opted not to consider Black as a quality gate necessary to advance in the pipeline), we would add the PYTHON_BLACK_DISABLE_ERRORS
and PYTHON_PYLINT_DISABLE_ERRORS
directives to the .mega-linter.yml
file:
---
# fail when finding errors
DISABLE_ERRORS: false
# Don't let Black block deployments
PYTHON_BLACK_DISABLE_ERRORS: true
# Don't let Pylint block deployments either
PYTHON_PYLINT_DISABLE_ERRORS: true
# DO block deployments from Checkov findings
REPOSITORY_CHECKOV_DISABLE_ERRORS: false
The DISABLE_ERRORS
and REPOSITORY_CHECKOV_DISABLE_ERRORS
lines are unnecessary (they're set to their default values) but makes it clear what's going on.
I saw DISABLE_ERRORS_LINTERS accepts a list of linters to enable, but only result in warnings, not errors (failures). So, to replicate the previous example, it would look like:
---
# fail when finding errors
DISABLE_ERRORS: false
# don't throw errors (failures) for the following linters
DISABLE_ERRORS_LINTERS: [PYTHON_BLACK, PYTHON_PYLINT]
# DO block deployments from Checkov findings
REPOSITORY_CHECKOV_DISABLE_ERRORS: false
In retrospect, the idea of having MegaLinter error / fail in only certain circumstances seems reasonable (so reasonable that there are multiple ways of setting it up already available) and may have some merit to documenting. My approach (multiple configuration files), while plausible, is unnecessary given what's already there. I suppose one could include it in the documentation for the sake of completion, but knowing what I know now, it wouldn't be my first choice.
I am wondering, though, if the documentation (e.g., FAQ) could be expanded upon, possibly with curated user-contributed content. If there's value in that, I'm happy to help with the execution.
(I reopened this to signal the continuation of the discussion; if it's better to have it closed, I'm fine with that, too. Whatever works for everyone else is cool with me.)
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.
I think the DISABLE_ERRORS_LINTERS is clear enough :)
Maybe we should add it as uncommentable property in the default workflow ?
Is your feature request related to a problem? Please describe.
The "problem" we're encountering with getting teams to adopt MegaLinter is folks fearing that they don't want linter warnings to block their development progress.
Describe the solution you'd like
We're using two MegaLinter configuration files: one is for stuff we want to block deployment (e.g., security-related) while the other is for linters.
So, it may be nice if we documented how one could set multiple runs (e.g., GitHub Actions), each with different
MEGALINTER_CONFIGURATION
environment variables set for blocking (e.g.,DISABLE_ERRORS
set tofalse
for theREPOSITORY_*
scanners) and another for non-blocking (e.g.,DISABLE_ERRORS
set totrue
, presumably with the desired linters that aren't in the blocking list).Describe alternatives you've considered
The feature request is for documentation, maybe to the FAQ page. I'm happy to do the work. My "request" here is for feedback on:
Additional context
I'm not looking to introduce any more work -- I'm looking for some thoughts. If you don't think this is a good use of time, that's fine with me -- no hurt feelings.