Allow to exclude rules from code analysis.

[CaBazaga]

Is your feature request related to a problem? Please describe.
I'm getting "Context access might be invalid: ENVVAR_NAME" for some environment variables I'm setting dynamically
on previous steps by:

run |
  env_var_name=some_bash_code_to_get_value
  echo "ENVVAR_NAME=$env_var_name" >> $GITHUB_ENV

so any alter reference like

${{ env.ECR_URI }}

Casts the given warning.

I understand the warning is legit, still I'll keep the code as it is, it works flawlessly and I'll not get the the reference if the value
has not been set previously, but having those warnings highlighted and counted on VSCode "problems" panel is annoying.

Specially getting them on tens, I do make a extended usage of setting GITHUB_ENV variables during workflows.

Describe the solution you'd like
I think that a way to ignore some rules on the linter, as done for several other lintees I use will be quite useful.

For example I can add this lines to my setup.cfg file to set the pycodestyle linting max length and ignore some errors and warnings.

[pycodestyle]
max-line-length = 89
ignore = E133, E226, W503

[felipesu19]

We have an issue for this in the backlog, i'm going to close this issue and link it in that issue!

[CaBazaga]

Hi @felipesu19

It's not the same feature requested, not even close, although it may seem it is.

That issue is about adding comment tags to suppress linting of specific lines.

My request is to configure the linter itself to suppress the check of specific rules.
I.e: In extend "Be able to configure the github actions linter behaviour"

Line tagging, if made simple, will prevent all rules to be checked on a single line.
Usually you don't want that, so you'll need to make a complex tag to specify which rules you want to exclude for that single line, and do that for each line u need it, may be several tens on a project with extend and complex CI/CD pipelines.

The configuration approach prevents the linter to check some rules without the need for you to "dirty" your code with "linter specific" comment tags, which is even worse on a shared environment were you may find different linters in use. 😨

While I may find some use cases for line tagging, on my experience most cases what i required was to remove a full rule from the linter's ruleset, some at the point that doing the same with line tags would have required me to tag more than 50% of my code. 😮

[jasperfirecai2]

If you are familiar with linters like the example in my issue, you'd know that there are statements for all sorts of use cases, and that they have config files too. You could disable any and all rules for a file, for a line, for a section, etc. You wouldn't be commenting suppression anywhere near 50% of your code, especially on a complex pipeline. Regardless, the option of using a config file or extension setting was already put on the table in that Issue. You could've commented on it there to represent your use case instead.