change: add file: Lintable argument to <rule_class>.match{,task} methods

[ssato]

Add file: Lintable argument to match and matchtask methods of the rule
classes because there are cases that it is necessary to do some analyses
depends on the context, that is, file: Lintable, such like the followings.

• want to restrict tasks in 'main.yml' use include_tasks only
• want to restrict the level of inclusions with include_tasks to 2
• restrict keywords can be used depends on file path or name
• inhibit some keywords are used in the line depends on file name

Signed-Off-By: Satoru SATOH satoru.satoh@gmail.com

[ssbarnea]

@ssato I do agree that Lintable should be exposed, at least for the matchtask.

For match(), it gets quite complicated and my plans were to deprecate and remove it. I personally see no good reason why a rule should look at a text line, especially as we are no longer doing YAML validations ourselves. IMHO, all the checks should be done using the already loaded data, not the source file.

Example:

myvar: >
  foo
  bar

The construct above represents the same thing as myvar: foo bar and our rules should focus on these.

The really tricky issue is that both of these changes will break all custom rules people may have, so we would need to do them in v6.

How about a compromise for matchtask that should avoid breaking users: add the Lintable argument as optional (second arg). I can see how a change like that would work, as I would not have to worry about undesired side-effects.

[ssato]

@ssbarnea Thanks a lot for your feedbacks!

@ssato I do agree that Lintable should be exposed, at least for the matchtask.

For match(), it gets quite complicated and my plans were to deprecate and remove it. I personally see no good reason why a rule should look at a text line, especially as we are no longer doing YAML validations ourselves. IMHO, all the checks should be done using the already loaded data, not the source file.

Absolutely right. I removed that part modify .match() from the change to simplify it.

The really tricky issue is that both of these changes will break all custom rules people may have, so we would need to do them in v6.

How about a compromise for matchtask that should avoid breaking users: add the Lintable argument as optional (second arg). I can see how a change like that would work, as I would not have to worry about undesired side-effects.

Also I fully agree with you. I updated to allow calling matchtask() w/o the file: Lintable argument by setting it to None by default.

I pushed another commit brings these updates to make these changes easier to understand.
Could you please review it again? If those are OK, I'll squash that commit to the previous commit and 'git push -f' again.

[ssbarnea]

Clearly these calls use incorrect order or arguments. I hope they fail the linting as I do not want to see others doing the same mistake.

[ssbarnea]

I did spot one error you need to fix, but in general it looks ok.

Run the "tox -e lint,py" locally and once all CI jobs are fixed it should be ready to merge.

[ssato]

I did spot one error you need to fix, but in general it looks ok.

Run the "tox -e lint,py" locally and once all CI jobs are fixed it should be ready to merge.

Thanks for your quick feedback!

I fixed all of the issues AFAIK, squashed commits and pushed with -f for merge.
At least 'tox -e lint,py39-devel,py39-ansible29,py36-ansible29' are passed locally.