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

[Jeff King <peff@peff.net>]

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

> 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.

> 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