PR and intake jobs should run the build instead of the check task

[alpar-t]

Currently the javadoc task is not part of check so javadoc failures will be discovered very late.

One reason for running check instead of build is that docker might not be available and the first one skips what can't be ran while the lather fails.
This however should not be an issues as the PR and intake workers are guaranteed to have docker.

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Build)

[rjernst]

Perhaps we could run javadoc specifically as part of the docs job in CI-PR? Or have another docs like job. One reason we didn't want this as part of check was the time it takes (several minutes IIRC).

[alpar-t]

It took 1m 17s for me https://gradle-enterprise.elastic.co/s/nunb23tprb5fu.
It would likely take much less in CI given the difference in the number of workers. I don't think it's worth complicating CI over it.

AFAIK not running javadoc was never intentional, it's an oversight from when we split the PR checks, so we should have buildPart1 instead of checkPart1 .

[mark-vieira]

Doing some testing with PR checks, doing a full build vs just adding javadoc to the check tasks adds about 30s to each build. While this doesn't seem like a lot, I'm still inclined to just wire up the javadoc task as there's zero benefit to all the extra stuff done by build such as building javadoc and source JARs and we're starting to get to the point where future build optimizations are going to be in 30s or less increments.

[alpar-t]

ok, let's try that. We can always backtrack if we find other stuff in build that is prone to breaking often ( although not vert likely given that javadoc itself didn't break all that often ) and we still have jobs that do run build in CI.