Reduce the impact of Maven Central outages

[MiguelWeezardo]

Description

When setup-java action is called with maven cache, a cache entry is uploaded upon job success.

Cache keys for Maven are based on a hash of all pom.xml files in the repository.
We need to ensure that cache entries contain all Trino dependencies.

If a PR which compiles just one module M gets merged after creating a cache entry, subsequent PRs which don't change any pom.xml files will use that cache entry and will be forced to download all dependencies which weren't on M's dependency list. Not only is this slow, it also introduces a failure point since Maven Central suffers from occasional outages.

This should help with issues like #14618.

Non-technical explanation

Make sure Maven cache contains all Trino dependencies, to avoid downloading them during build.

Release notes

(x) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[findepi]

This should help with issues like #14618.

Did you mean "fixes #14618."

Will this fix #14803 too?

[hashhar]

At this point I think it'd be much simpler to add a step which does mvn dependency:go-offline and use that to prepare cache instead of trying to keep track of which job produces most complete cache.

(Or add mvn dependency:go-offline to an existing job which we chose to populate cache).

[MiguelWeezardo]

At this point I think it'd be much simpler to add a step which does mvn dependency:go-offline and use that to prepare cache instead of trying to keep track of which job produces most complete cache.

(Or add mvn dependency:go-offline to an existing job which we chose to populate cache).

I didn't know about depedency:go-offline, this is exactly what I was looking for. Thanks!

[MiguelWeezardo]

This should help with issues like #14618.

Did you mean "fixes #14618."

I'd rather not overpromise, since there are many failure modes this PR won't help with, and they all look like #14618

Will this fix #14803 too?

#14803 looks like a network problem in GitHub.
I don't think this PR will solve it, since it relies on GitHub network working to get cache entries.

[hashhar]

@MiguelWeezardo It'd be useful to measure how much time a separate mvn dependency:go-offline JOB adds vs adding a mvn dependency:go-offline STEP in the build-pt (or some other job which always runs).

[MiguelWeezardo]

@MiguelWeezardo It'd be useful to measure how much time a separate mvn dependency:go-offline JOB adds vs adding a mvn dependency:go-offline STEP in the build-pt (or some other job which always runs).

I misread your comment, sorry. I agree it should be faster by adding a new step not a whole job.

[hashhar]

LGTM. (I did try to verify all jobs except build-pt have the "Clean local Maven repo" step but I obviously did it by eye so would appreciate someone rechecking).

[nineinchnick]

BTW GitHub recently added a view for caches, when you go to the actions tab check the lower left corner:

[MiguelWeezardo]

BTW GitHub recently added a view for caches, when you go to the actions tab check the lower left corner:

Yes, and it's clear that some incomplete caches are being created (notice the size of the last entry):

setup-java-Linux-maven-39f17690b8084b8b1be072dcec83301adcf1f8463641b66daf83d0f630c0563d 910 MB cached 3 days ago
[master](https://github.com/trinodb/trino)
Last used 2 hours ago

setup-java-Linux-maven-e013dcb75512fe8010221ad18705aac972a1323919bf0cb2cc9dabdf9a37550a 890 MB cached 11 hours ago
refs/pull/14810/merge
Last used 2 hours ago

setup-java-Linux-maven-302a2568a4b5ea4116e29a722c4965334b37df5633537eb8e925fa2d88563c96 270 MB cached 4 hours ago
refs/pull/14812/merge
Last used 3 hours ago

[hashhar]

LGTM. Thanks.

[nineinchnick]

Note that downloading all dependencies adds 1.5 minutes to the maven-checks job:

It's not always needed - only when there was no cache hit. I think it's ok, given that:

• it should improve the resiliency of other jobs
• it should use the cache after this PR gets merged and when the cache rebuilds

[hashhar]

Thanks @MiguelWeezardo for this.