Git development
 help / color / mirror / Atom feed
* [PATCH] ci: bump debian-11 job to debian-12
@ 2026-09-05 13:58 Jeff King
  2026-09-05 16:32 ` Junio C Hamano
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Jeff King @ 2026-09-05 13:58 UTC (permalink / raw)
  To: git; +Cc: brian m. carlson, Patrick Steinhardt

Debian 11 just recently went out of its LTS period, and is unmaintained
by the project (there is "Extended LTS", but it is a paid service
provided by a third party).

The point of the debian-11 job was to cover older releases in the LTS
state, per ac112fd4f0 (Add additional CI jobs to avoid accidental
breakage, 2024-10-31). Bumping to debian-12 will cover us there for the
next 2 years.

Signed-off-by: Jeff King <peff@peff.net>
---
I started looking at this because I got an apt failure on a debian-11
job today. It might have just been a transient mirror failure (although
it reproduced for several minutes afterwards). But this seems like the
right step forward anyway.

I tested the GitHub job, but not the GitLab one. They should be pulling
the same docker images, though, so I would expect it to Just Work.

 .github/workflows/main.yml | 6 +++---
 .gitlab-ci.yml             | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 205325eb33..a0c3f53c6d 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -411,9 +411,9 @@ jobs:
         # A RHEL 8 compatible distro.  Supported until 2029-05-31.
         - jobname: almalinux-8
           image: almalinux:8
-        # Supported until 2026-08-31.
-        - jobname: debian-11
-          image: debian:11
+        # Supported until 2028-06-30.
+        - jobname: debian-12
+          image: debian:12
     env:
       jobname: ${{matrix.vector.jobname}}
       CC: ${{matrix.vector.cc}}
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 0242283c3c..cd6fd4a504 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -71,9 +71,9 @@ test:linux:
       # A RHEL 8 compatible distro.  Supported until 2029-05-31.
       - jobname: almalinux-8
         image: almalinux:8
-      # Supported until 2026-08-31.
-      - jobname: debian-11
-        image: debian:11
+      # Supported until 2028-06-30.
+      - jobname: debian-12
+        image: debian:12
   artifacts:
     paths:
       - t/failed-test-artifacts
-- 
2.55.0.1127.g25100ff258

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-05 13:58 [PATCH] ci: bump debian-11 job to debian-12 Jeff King
@ 2026-09-05 16:32 ` Junio C Hamano
  2026-09-06 15:11 ` Jeff King
  2026-09-07  6:03 ` Patrick Steinhardt
  2 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2026-09-05 16:32 UTC (permalink / raw)
  To: Jeff King; +Cc: git, brian m. carlson, Patrick Steinhardt

Jeff King <peff@peff.net> writes:

> Debian 11 just recently went out of its LTS period, and is unmaintained
> by the project (there is "Extended LTS", but it is a paid service
> provided by a third party).
>
> The point of the debian-11 job was to cover older releases in the LTS
> state, per ac112fd4f0 (Add additional CI jobs to avoid accidental
> breakage, 2024-10-31). Bumping to debian-12 will cover us there for the
> next 2 years.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I started looking at this because I got an apt failure on a debian-11
> job today. It might have just been a transient mirror failure (although
> it reproduced for several minutes afterwards). But this seems like the
> right step forward anyway.
>
> I tested the GitHub job, but not the GitLab one. They should be pulling
> the same docker images, though, so I would expect it to Just Work.

Thanks.  I also noticed debian-11 job failing.  Will queue.



>
>  .github/workflows/main.yml | 6 +++---
>  .gitlab-ci.yml             | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> index 205325eb33..a0c3f53c6d 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -411,9 +411,9 @@ jobs:
>          # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>          - jobname: almalinux-8
>            image: almalinux:8
> -        # Supported until 2026-08-31.
> -        - jobname: debian-11
> -          image: debian:11
> +        # Supported until 2028-06-30.
> +        - jobname: debian-12
> +          image: debian:12
>      env:
>        jobname: ${{matrix.vector.jobname}}
>        CC: ${{matrix.vector.cc}}
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 0242283c3c..cd6fd4a504 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -71,9 +71,9 @@ test:linux:
>        # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>        - jobname: almalinux-8
>          image: almalinux:8
> -      # Supported until 2026-08-31.
> -      - jobname: debian-11
> -        image: debian:11
> +      # Supported until 2028-06-30.
> +      - jobname: debian-12
> +        image: debian:12
>    artifacts:
>      paths:
>        - t/failed-test-artifacts

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-05 13:58 [PATCH] ci: bump debian-11 job to debian-12 Jeff King
  2026-09-05 16:32 ` Junio C Hamano
@ 2026-09-06 15:11 ` Jeff King
  2026-09-07  6:03   ` Patrick Steinhardt
  2026-09-07  6:03 ` Patrick Steinhardt
  2 siblings, 1 reply; 8+ messages in thread
From: Jeff King @ 2026-09-06 15:11 UTC (permalink / raw)
  To: git; +Cc: brian m. carlson, Patrick Steinhardt

On Sat, Sep 05, 2026 at 09:58:22AM -0400, Jeff King wrote:

> I started looking at this because I got an apt failure on a debian-11
> job today. It might have just been a transient mirror failure (although
> it reproduced for several minutes afterwards). But this seems like the
> right step forward anyway.

BTW, I noticed that the linux32 build is using ubuntu 20.04, which has
been out of LTS for a year. But bumping isn't really an option; they
dropped i386 platform support, and so has Debian.

I'm mostly inclined to leave it unless/until it starts creating
headaches. To some degree, if we cannot even find an image to test
again, it might not be an important enough platform to care about. But I
can also imagine there is a long tail of oddball 32-bit platforms that
Git does run on (like small ARM chips), and it's nice to at least have
some coverage. Possibly there's an ARM image we could use (looks like
armhf?).

We also seem to use 20.04 for linux-TEST-vars. On the surface there's no
reason it couldn't be using ubuntu-latest, though I think this may be
one of those cases where it's doing double duty as "test exotic configs"
and "test on an older platform". But might be worth bumping to the
oldest in-scope LTS.

All out of scope for this patch, and mostly I'm inclined to ignore it
for now until we hit problems (and then decide if it's worth
accommodating or if old systems are too old).

-Peff

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-06 15:11 ` Jeff King
@ 2026-09-07  6:03   ` Patrick Steinhardt
  0 siblings, 0 replies; 8+ messages in thread
From: Patrick Steinhardt @ 2026-09-07  6:03 UTC (permalink / raw)
  To: Jeff King; +Cc: git, brian m. carlson

On Sun, Sep 06, 2026 at 11:11:37AM -0400, Jeff King wrote:
> On Sat, Sep 05, 2026 at 09:58:22AM -0400, Jeff King wrote:
> 
> > I started looking at this because I got an apt failure on a debian-11
> > job today. It might have just been a transient mirror failure (although
> > it reproduced for several minutes afterwards). But this seems like the
> > right step forward anyway.
> 
> BTW, I noticed that the linux32 build is using ubuntu 20.04, which has
> been out of LTS for a year. But bumping isn't really an option; they
> dropped i386 platform support, and so has Debian.
> 
> I'm mostly inclined to leave it unless/until it starts creating
> headaches. To some degree, if we cannot even find an image to test
> again, it might not be an important enough platform to care about. But I
> can also imagine there is a long tail of oddball 32-bit platforms that
> Git does run on (like small ARM chips), and it's nice to at least have
> some coverage. Possibly there's an ARM image we could use (looks like
> armhf?).

I agree that in the best case we'd find an alternative that works on 32
bit. But as you say, the list of x86 distros that still have support for
32 bit is shrinking quite a bit these days.

One of the bigger distros that still supports it properly is Alpine
Linux. We already support it via linux-musl-meson, so it should be easy
enough to extend. In theory, we could even merge these two jobs into a
single job. We'd of course lose 32 bit glibc support, but that might be
fine.

> We also seem to use 20.04 for linux-TEST-vars. On the surface there's no
> reason it couldn't be using ubuntu-latest, though I think this may be
> one of those cases where it's doing double duty as "test exotic configs"
> and "test on an older platform". But might be worth bumping to the
> oldest in-scope LTS.

Yeah, might be worth it. It would've been great if they had a tag for
this so we odn't have to bump ourselves, but on the other hand it's only
a small bit of churn.

Patrick

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-05 13:58 [PATCH] ci: bump debian-11 job to debian-12 Jeff King
  2026-09-05 16:32 ` Junio C Hamano
  2026-09-06 15:11 ` Jeff King
@ 2026-09-07  6:03 ` Patrick Steinhardt
  2026-09-11  2:19   ` Jeff King
  2 siblings, 1 reply; 8+ messages in thread
From: Patrick Steinhardt @ 2026-09-07  6:03 UTC (permalink / raw)
  To: Jeff King; +Cc: git, brian m. carlson

On Sat, Sep 05, 2026 at 09:58:22AM -0400, Jeff King wrote:
> Debian 11 just recently went out of its LTS period, and is unmaintained
> by the project (there is "Extended LTS", but it is a paid service
> provided by a third party).
> 
> The point of the debian-11 job was to cover older releases in the LTS
> state, per ac112fd4f0 (Add additional CI jobs to avoid accidental
> breakage, 2024-10-31). Bumping to debian-12 will cover us there for the
> next 2 years.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I started looking at this because I got an apt failure on a debian-11
> job today. It might have just been a transient mirror failure (although
> it reproduced for several minutes afterwards). But this seems like the
> right step forward anyway.

I noticed that the Debian jobs became flaky lately, too.

> I tested the GitHub job, but not the GitLab one. They should be pulling
> the same docker images, though, so I would expect it to Just Work.

Yeah, same.

> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> index 205325eb33..a0c3f53c6d 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -411,9 +411,9 @@ jobs:
>          # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>          - jobname: almalinux-8
>            image: almalinux:8
> -        # Supported until 2026-08-31.
> -        - jobname: debian-11
> -          image: debian:11
> +        # Supported until 2028-06-30.
> +        - jobname: debian-12
> +          image: debian:12
>      env:
>        jobname: ${{matrix.vector.jobname}}
>        CC: ${{matrix.vector.cc}}
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 0242283c3c..cd6fd4a504 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -71,9 +71,9 @@ test:linux:
>        # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>        - jobname: almalinux-8
>          image: almalinux:8
> -      # Supported until 2026-08-31.
> -      - jobname: debian-11
> -        image: debian:11
> +      # Supported until 2028-06-30.
> +      - jobname: debian-12
> +        image: debian:12
>    artifacts:
>      paths:
>        - t/failed-test-artifacts

The changes look good, but I wonder whether we want to swap to the
"oldstable" tag instead. That points to debian-12, too, and might result
in less churn going forward.

Patrick

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-07  6:03 ` Patrick Steinhardt
@ 2026-09-11  2:19   ` Jeff King
  2026-09-11  5:09     ` Patrick Steinhardt
  2026-09-11 15:42     ` Junio C Hamano
  0 siblings, 2 replies; 8+ messages in thread
From: Jeff King @ 2026-09-11  2:19 UTC (permalink / raw)
  To: Patrick Steinhardt; +Cc: git, brian m. carlson

On Mon, Sep 07, 2026 at 08:03:34AM +0200, Patrick Steinhardt wrote:

> > +      # Supported until 2028-06-30.
> > +      - jobname: debian-12
> > +        image: debian:12
> >    artifacts:
> >      paths:
> >        - t/failed-test-artifacts
> 
> The changes look good, but I wonder whether we want to swap to the
> "oldstable" tag instead. That points to debian-12, too, and might result
> in less churn going forward.

I was all ready to agree and propose a patch, but I think it might be
more complicated. The "old" flags flip when a new stable version is
released, but what we really care about is things leaving LTS. And the
two are not really aligned.

So if we wanted the oldest supported Debian release, that would have
been "oldoldstable" (debian-11) until August 31st of this year. But
after that, we want "oldstable" (debian-12), which is now the oldest
thing under LTS. And that will be true until probably next summer, when
debian-14 is released, at which point we'd want to stay on it by
switching to "oldoldstable" again for another year.

The offset comes from the fact that Debian releases approximately every
2 years, but with a 5-year LTS, and they never align.

If we track oldstable, then every other year we're not using the oldest
supported release (because the prior release is still in LTS). Or we
track oldoldstable, which means every other year we're using a release
that's no longer supported. Or we flip-flop between them once a year,
when oldoldstable goes out of support.

Which makes me inclined to just keep the current scheme: use the numeric
codes and just bump them every 2 years or so when they go out of
support. And we can even put it off until the out-of-support release
starts causing problems like it did here.

-Peff

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-11  2:19   ` Jeff King
@ 2026-09-11  5:09     ` Patrick Steinhardt
  2026-09-11 15:42     ` Junio C Hamano
  1 sibling, 0 replies; 8+ messages in thread
From: Patrick Steinhardt @ 2026-09-11  5:09 UTC (permalink / raw)
  To: Jeff King; +Cc: git, brian m. carlson

On Thu, Sep 10, 2026 at 10:19:33PM -0400, Jeff King wrote:
> On Mon, Sep 07, 2026 at 08:03:34AM +0200, Patrick Steinhardt wrote:
> 
> > > +      # Supported until 2028-06-30.
> > > +      - jobname: debian-12
> > > +        image: debian:12
> > >    artifacts:
> > >      paths:
> > >        - t/failed-test-artifacts
> > 
> > The changes look good, but I wonder whether we want to swap to the
> > "oldstable" tag instead. That points to debian-12, too, and might result
> > in less churn going forward.
> 
> I was all ready to agree and propose a patch, but I think it might be
> more complicated. The "old" flags flip when a new stable version is
> released, but what we really care about is things leaving LTS. And the
> two are not really aligned.
> 
> So if we wanted the oldest supported Debian release, that would have
> been "oldoldstable" (debian-11) until August 31st of this year. But
> after that, we want "oldstable" (debian-12), which is now the oldest
> thing under LTS. And that will be true until probably next summer, when
> debian-14 is released, at which point we'd want to stay on it by
> switching to "oldoldstable" again for another year.
> 
> The offset comes from the fact that Debian releases approximately every
> 2 years, but with a 5-year LTS, and they never align.
> 
> If we track oldstable, then every other year we're not using the oldest
> supported release (because the prior release is still in LTS). Or we
> track oldoldstable, which means every other year we're using a release
> that's no longer supported. Or we flip-flop between them once a year,
> when oldoldstable goes out of support.
> 
> Which makes me inclined to just keep the current scheme: use the numeric
> codes and just bump them every 2 years or so when they go out of
> support. And we can even put it off until the out-of-support release
> starts causing problems like it did here.

Sounds good, let's stick with the current patch then. Thanks!

Patrick

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] ci: bump debian-11 job to debian-12
  2026-09-11  2:19   ` Jeff King
  2026-09-11  5:09     ` Patrick Steinhardt
@ 2026-09-11 15:42     ` Junio C Hamano
  1 sibling, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2026-09-11 15:42 UTC (permalink / raw)
  To: Jeff King; +Cc: Patrick Steinhardt, git, brian m. carlson

Jeff King <peff@peff.net> writes:

> If we track oldstable, then every other year we're not using the oldest
> supported release (because the prior release is still in LTS). Or we
> track oldoldstable, which means every other year we're using a release
> that's no longer supported. Or we flip-flop between them once a year,
> when oldoldstable goes out of support.
>
> Which makes me inclined to just keep the current scheme: use the numeric
> codes and just bump them every 2 years or so when they go out of
> support. And we can even put it off until the out-of-support release
> starts causing problems like it did here.

Sounds sensible to me.  Thanks for thinking this through.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-09-11 15:42 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-05 13:58 [PATCH] ci: bump debian-11 job to debian-12 Jeff King
2026-09-05 16:32 ` Junio C Hamano
2026-09-06 15:11 ` Jeff King
2026-09-07  6:03   ` Patrick Steinhardt
2026-09-07  6:03 ` Patrick Steinhardt
2026-09-11  2:19   ` Jeff King
2026-09-11  5:09     ` Patrick Steinhardt
2026-09-11 15:42     ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox