max-tasks: Limit the number of tasks in a task file

[cidrblock]

Starting to pull in possible rule ideas from the community of practice: redhat-cop/automation-good-practices#64

Limiting the total number of tasks in a single task file would encourage the use of includes, possibly leading to more reusable discrete tasks.

This would also add to the readability of the task files as each would have a file name indicating the summary action it performs.

30 was thrown in here as an idea, it could be higher, but I think having it too low would move the complexity to the file system.

[rohitthakur2590]

I'll work on this one.

[MarkusTeufelberger]

This is no longer recommended explicitly by the way: https://github.com/redhat-cop/automation-good-practices/tree/main/coding_style

It only reads

Break complex task files down into discrete parts.

Rationale
Task files that are very or and/or contain highly nested blocks are difficult to maintain. Breaking a large or complex task file into multiple discrete files makes it easier to read and understand what is being done in each part.

There is no specific number of tasks given.

[ssbarnea]

@MarkusTeufelberger As part of the implementation for this rule, we will gather some data from all content published on public hub and find a suitable value that is very unlikely to be hit by normal usage. Also, the rule could be disabled by the user anyway.

This could be seen as related to pylint too-complex rule which is based on mccable cyclomatic complexity, something that does not really apply to ansible content. I suspect the number will be somewhere between 40-100.

Also the plan is to limit the number of tasks per block level (top level could also be considered a level, so you might have more tasks than the limit inside a single file without hitting the rule if they are nested.

Still, final implementation is still subject to discussions so any feedback is more than welcomed here. IMHO, we should be able to look at bad players once we can count the complexity and decide if the rule works or not based on rate of false positives.

If we discover that only ~50% of long tasks files should really be split in other files, we will not do the rule. But if more than 80% are and less than 20% are false positives, we might have a case for keeping it.

[ssbarnea]

Lets try an first implementation checking for 100 tasks, user configurable and counted per file (not inside each branch).