[CI] Run linting for only docs

[v1v]

What does this PR do?

Run make check when there are only doc changes, otherwise, it keeps as usual.

Why is it important?

Otherwise the linting is not executed since it's delegated to the specific beat which only run when no doc changes.

Related issues

• Closes Linting in jenkins doesn't detect some issues in modules docs #22899
• Caused by ci: improve linting speed #22103

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #23099 opened

• Start Time: 2020-12-14T09:24:37.120+0000

• Duration: 58 min 35 sec

Test stats 🧪

Test	Results
Failed	0
Passed	17427
Skipped	1379
Total	18806

Steps errors

Expand to view the steps failures

Terraform Apply on x-pack/metricbeat/module/aws

• Took 0 min 19 sec . View more details on here

Terraform Apply on x-pack/metricbeat/module/aws

• Took 0 min 15 sec . View more details on here

💚 Flaky test report

Tests succeeded.

Expand to view the summary

Test stats 🧪

Test	Results
Failed	0
Passed	17427
Skipped	1379
Total	18806

[jsoriano]

Thanks for working on a fix for this!

Something I think we are also missing since #22103 is that some module docs files generated under filebeat/docs and metricbeat/docs depend on the docs of x-pack modules, and I think we are not triggering any OSS build after changes in x-pack.
Perhaps for that we should trigger a make check in oss if x-pack is modified, but I am ok with doing it as a different change.

[v1v]

@jsoriano

Perhaps for that we should trigger a make check in oss if x-pack is modified, but I am ok with doing it as a different change.

Yes, I'd prefer to create a specific issue for that particular scenario :)

[kuisathaverat]

Is possible to run the lint stage(Jenkinsfile.yml) of each beat? it is the same but in parallel so faster

[v1v]

That's another approach to solve this issue:

• Either to exclude the ONLY_DOCS when in the Builds&Tests dynamic stages. But it will also run the build/tests stages, and if flaky tests then it might cause failed builds for only docs changes.
• Or this approach

That's the current implementation, but my aim with this PR was to avoid changing the current implementation but enabling the make check only for the DOCS changes.

In both cases, the output is the same, I guess

[kuisathaverat]

let's live with it, but takes 15 min :(

[v1v]

It's only for docs changes, if any kind of code changes, then it will work as used to be.