Re: CI setup

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Tue, 05 Aug 2025 08:23:53 +0200
Newsgroups	gmane.comp.gnu.inetutils.bugs
Message-ID	<[email protected]>
Bruno Haible via Bug reports for the GNU Internet utilities
<[email protected]> writes:

> Simon Josefsson wrote:
>> My view is changing towards seeing gnulib like just any other build-time
>> dependency.  We are using versioned build dependencies of
>> Trisquel/Guix/Debian/RHEL and autoconf, automake, help2man, etc in CI/CD
>> because we want to test those versions.  We aren't using bleeding edge
>> autoconf, automake, etc in CI/CD when building inetutils.  So using a
>> specific gnulib commit seems to match how we treat all other build
>> dependencies.
>
> That's a valid way to see things, yes. Some time ago, Tim Rühsen configured
> the Gnulib CI to use the bleeding edge Debian. But I don't want to spend
> time debugging Debian, therefore I picked a fixed Debian release instead.

Yes, I've had this challenge too and after going back and forth between
use of stable and testing OS releases a couple of time, I realized that
both have their use.  I now add jobs for both pinned version releases
(because that's what users tends to use and what I want to check works)
and testing/rolling releases (to catch early regressions before they hit
released versions).  Then during times where Debian testing is
completely broken, I can just ignore the failing jobs, and still have
passing jobs that give confidence in any patches.

>> However I do agree with you about the utility of ALSO building inetutils
>> with bleeding edge gnulib.
>
> Implemented through
> https://github.com/gnu-inetutils/ci-check/commit/b68ebfb39d74809422cf8452aefc7309f0b6940e
> Let's see how it works...

Nice!  I hope to add a use-latest-gnulib CI job to gitlab too.  For the
remote possibility that gnulib master is known buggy for a some extended
set of time, having the inetutils CI not test intended gnulib commit
depending on which day it is running may be a bit annoying when fixing
things and desiring a predictable CI.  But we'll see.

There are already similar issues around midnight, if you prepare a 'make
release' tarball at 23:59 in one CI/CD job and another 'make release'
tarball at 00:01 in another CI/CD job, the tarballs could end up being
different due to embedded build-time dates.  I think I have fixed most
glaring examples of this in some projects, and it was some months ago it
last happened.  The take away is that build time should not matter: when
there is a desire to look at timestamps, derive it from the latest git
commit time instead.

/Simon
signature.asc (application/pgp-signature, 1.2 KB)