Re: [PATCH 2/2] ci: bump ubuntu image version for static-analysis job

From: Jeff King <peff@peff.net>
Date: Sep 5, 2026, 13:52 UTC
Message-ID: <20260905135259.GB3914039@coredump.intra.peff.net>
In-Reply-To: <andoDRDn5RvgNHrl@szeder.dev>

On Sat, Aug 08, 2026 at 07:31:57PM +0200, SZEDER Gábor wrote:

Show 20 quoted lines

> Using these to run 'make coccicheck' on 630cf86933, i.e. 'seen' on or
> around 2026-07-14, which contained a024a5818c (branch: add
> --delete-merged <branch>, 2026-07-14) with those problematic loop
> counter variables I got the following results:
> 
>   - 1.1.1: 1437.78user 56.66system 2:10.29elapsed 1146%CPU (0avgtext+0avgdata 223896maxresident)k
> 
>   - 1.2.0: ctrl-c after 2.5h.  The bulk of the work was done in about
>            10 minutes, but processing 'builtin/branch.c' seemed to
>            hang forever.
> 
>   - 1.3.1: 6532.81user 106.75system 9:35.04elapsed 1154%CPU (0avgtext+0avgdata 635592maxresident)k
> 
> So my Coccinelle 1.1.1 didn't hang, moreover, it was about 4.5 times
> faster than 1.3.1.  I got similar runtime differences between 1.1.1
> and 1.3.1 when checking e.g. v2.55.0 or current master; in these cases
> 1.2.0 didn't hang, but took about the same time as 1.3.1.
> 
> Am I doing something wrong?   Or is everyone else is doing something
> wrong? :)

I'd meant to circle back to this and get an answer, but ultimately...I don't have one. I was easily able to reproduce the forever-hang behavior building locally, and even bisected it. However IIRC I couldn't get 1.1.1 to build at all, so my bisect started a bit forward of that.

So I'm a little curious why we get different results, but not enough to sink a bunch more time into building and timing coccinelle myself.

Ultimately I think we'll end up on newer versions in the long run as old versions eventually become unavailable / uncompilable on newer platforms. So given mixed signals about timing, I think I'd still prefer moving forward in time as a general tie-breaker.

Show 14 quoted lines

> On a somewhat related note, for a while now we've been unnecessarily
> installing all the dependencies of the "build and test" jobs
> (compiler, build systems, apache, p4, jgit, etc.) for the various
> static analysis and the 'documentation' CI jobs as well.
> 
> I think this is because 707d2f2fe8 (CI: use "$runs_on_pool", not
> "$jobname" to select packages & config, 2021-11-23) started installing
> all those dependencies for jobs using 'ubuntu-latest', including the
> 'documentation' job as well, though this side-effect was not mentioned
> in the commit message.  The 'StaticAnalysis' and 'sparse' jobs were
> not affected at the time, because they were using a specific Ubuntu
> version, but then 0178420b9c (github-actions: run gcc-8 on
> ubuntu-20.04 image, 2022-11-25) came along and changed the pattern
> matching $runs_on_pool from 'ubuntu-latest' to 'ubuntu-*'.

It has always felt a little nuts to me that all of these CI jobs start with a vanilla base image and then "apt install" a bunch of packages. Surely there is some mechanism for caching that intermediate state as an image, at which point it is "free" to use it as the base for all of the jobs, whether they need all of it or not (modulo some extra bytes in the image, but to me that is way cheaper than the run-time cost of downloading and installing packages).

I know Docker has some support for automatically caching intermediate image states, but I don't think any of that applies here. From its perspective, the all of our ci scripts are running and mutating the container.

-Peff