Take out lint jobs from all workflows to a separated one

NETWAYS / ansible-collection-elasticstack

A collection to install and manage the Elastic Stack

GNU General Public License v3.0

9 stars 8 forks source link

Take out lint jobs from all workflows to a separated one #192

Closed afeefghannam89 closed 11 months ago

afeefghannam89 commented 1 year ago

It will be good to take out all lint jobs from all workflows files and build a separated linter workflow. Other corresponding workflows will only run if linter workflows ended successfully. What we achieve with this?

01- Compact code 02- Now, many pipelines/workflows will run if a change happens on .config/ansible-lint.yml or .yamllint. Only linter pipeline should be run in this case.

afeefghannam89 commented 1 year ago

@widhalmt what do you think about this? We should use in this case a lint job for the complete collection not like now, link_kiban, lint_beats, lint_elasticseach ......... the full lint job will take about 75 seconds. I do not think it will be a remarkable difference in time between the small lint job and the full one.

widhalmt commented 1 year ago

Yes. I agree with you. Separate linters only give overhead but as you said, it's just about a few seconds.

Having linters in the specific jobs and running a linter in the same pipeline before the whole tests only makes sense, if we bring back fail-fast. As I understand, GitHub will stop executing pipelines when one check has failed. This has drawbacks and benefits. But if we bring it back, running a linter before a pipeline helps with not wasting ressources for checks that won't work anyway.

Donien commented 1 year ago

I've created a branch to test using a reusable workflow for linting.

When changing linting rules, the whole repo is linted using yamllint . and all roles are linted using ansible-lint roles/.
When changing something about a role (e.g. kibana), only the role is linted using yamllint roles/kibana and ansible-lint roles/kibana. This happens as the first job within the given (role specific) workflow.
Drawback: When changing something about the rules themselves and about a role at the same time, two workflows will trigger; one for the general linting and one for the role specific changes (one for each role that is). Thus, in edge cases there would be a bit more overhead.

This is just a first draft on how this could be done.
If you have any ideas or suggestions on how to better deal with the issue, please let me know.