Avoid updating Ubuntu Docker image in PR builds

[MiguelWeezardo]

Description

Some issues with stability of Ubuntu repositories have surfaced lately.
Our Dockerfile tries to update packages in the base Ubuntu image, and when that fails, the entire maven-checks job fails.

We can use a build cache to avoid running these updates.

Additional context and related issues

#15807 (comment)
https://github.com/trinodb/trino/actions/runs/4004028582/jobs/6872683430

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`)

[MiguelWeezardo]

I'm also thinking about running buildx for multiple platforms in parallel: https://github.com/MiguelWeezardo/trino/tree/docker_buildx_parallel

[nineinchnick]

I'm also thinking about running buildx for multiple platforms in parallel: https://github.com/MiguelWeezardo/trino/tree/docker_buildx_parallel

Cool, but this is out of the scope of this PR. We're trying to improve resiliency against network issues. Let's get this working and merged first, and we can improve the duration of these jobs later.

[nineinchnick]

CI hit this:

#14 ERROR: error writing layer blob: GitHub Actions is temporarily unavailable. Please visit https://www.githubstatus.com/ for the status of our services.

I started wondering if it'll actually be more reliable.

Also, it doesn't look like it's using separate cache entries for every architecture. If it overwrites the cache for every arch, it won't be able to use it at all. WDYT on how to continue?

[MiguelWeezardo]

CI hit this:

#14 ERROR: error writing layer blob: GitHub Actions is temporarily unavailable. Please visit https://www.githubstatus.com/ for the status of our services.

I started wondering if it'll actually be more reliable.

Also, it doesn't look like it's using separate cache entries for every architecture. If it overwrites the cache for every arch, it won't be able to use it at all. WDYT on how to continue?

I'd like to check if an approach using inline caching will work. It seems to work locally on my laptop.

[MiguelWeezardo]

Seems relevant: https://dev.to/dtinth/caching-docker-builds-in-github-actions-which-approach-is-the-fastest-a-research-18ei

[MiguelWeezardo]

It seems that Docker cache cuts down the step time from ~9 minutes to ~7.

[nineinchnick]

LGTM % nitpicks

[nineinchnick]

@findepi, @hashhar PTAL, this is ready for review.

CI failures look like:

• Adding column in SQL Server connector sometimes fails even though column has been added successfully #12535
• Flaky io.trino.tests.product.kudu.TestKuduConnectoKerberosSmokeTest.kerberosAuthTicketExpiryTest #14441

[findepi]

Additional context and related issues

#15807 (comment) https://github.com/trinodb/trino/actions/runs/4004028582/jobs/6872683430

@MiguelWeezardo could this be an issue?

[findepi]

Some issues with stability of Ubuntu repositories have surfaced lately.
Our Dockerfile tries to update packages in the base Ubuntu image, and
when that fails, the entire maven-checks job fails.

Updates are not necessary (per Docker's philosophy, updates to the base image should be part of base image lifecycle), but we install new stuff too.

We can use layers from the latest trino image to avoid running
these updates.

We already have some retries

trino/core/docker/Dockerfile

Lines 29 to 30 in 257c2a5

	echo 'Acquire::Retries "3";' > /etc/apt/apt.conf.d/80-retries && \
	echo 'Acquire::http::Timeout "15";' > /etc/apt/apt.conf.d/80-timeouts && \

are these not sufficient?
what can we do to make them sufficient?

This change may get CI working, but we cannot rely on that for automated releases (once we have them), so would be nice to have some more self-contained solution

[findepi]

BTW this means CI won't see any updates to eclipse-temurin:17-jdk image only until we do a release.
So if eclipse-temurin:17-jdk updates affects us in any way, we won't know about that until our users know about that.

[findepi]

I am not well-versed in buildx.
if you want me to continue the review of this PR, I would recommend splitting this out to a follow-up

[MiguelWeezardo]

Additional context and related issues

#15807 (comment) https://github.com/trinodb/trino/actions/runs/4004028582/jobs/6872683430

@MiguelWeezardo could this be an issue?

Yes, that's the problem this PR is trying to solve by caching.
I've reported it as #15992, thanks for pointing that out.

[MiguelWeezardo]

I'm also considering adding more apt mirrors before running apt update so we have a fallback in case the main Ubuntu repo goes down.

[MiguelWeezardo]

I'm also considering adding more apt mirrors before running apt update so we have a fallback in case the main Ubuntu repo goes down.

Testing of that approach continues in MiguelWeezardo#14

[github-actions]

This pull request has gone a while without any activity. Tagging the Trino developer relations team: @bitsondatadev @colebow @mosabua

[mosabua]

@MiguelWeezardo and @nineinchnick .. is this work still ongoing and valid or do we want to close this PR?

[nineinchnick]

We paused the work for now. We got some initial feedback from Piotr that we need to address. We can close this now and reopen later.

[MiguelWeezardo]

The cache doesn't reliably solve the flaky Ubuntu repos issue. This approach might be useful for speeding up builds.