Re: Understanding CI in Salsa, timeouts and runners

Ben Hutchings <[email protected]> Tue, 02 Jun 2026 14:49:22 +0200
Newsgroups	gmane.linux.debian.devel.general
Message-ID	<[email protected]>
On Mon, 2026-06-01 at 23:18 -0300, Santiago Ruano Rincón wrote:
> El 31/05/26 a las 23:52, Leopold Palomo-Avellaneda escribió:
> > Hi,
> > 
> > 
> > I'm trying to help in packaging of fastdds [1]. It is a small monster
> > package.
> > 
> > After update all the patches to the new version, I pushed it to salsa.
> > However, I have not been able to built it because timeout.
> > 
> > I have modified the timeout in the project to 4h, however, still the limit
> > of 3h still is applied.
> > 
> > I have configured a runner in my university to build the package. They
> > connect to my runner, use the same image as salsa, but it fails because:
> > 
> > /usr/bin/bash: line 273: cd: /builds/robotics-team/fastdds/debian/output: No
> > such file or directory
> > WARNING: after_script failed, but job will continue unaffected: exit code 1
> > 
> > So,
> > 
> > 1) Can we use a private runner to a salsa project to build a packages, at
> > least in testing?
> 
> I think "E: unable to pick chroot mode automatically (use --mode for
> manual selection)" gives a better clue.
> 
> You runner needs to run privileged containers for being able to run
> (sbuild+)unshare.  Yeah, that is not idea for a 'docker' gitalb-runner
> executor in a locally shared runner.
> 
> > 2) How can I increase or how can we manage to build packages that needs a
> > lot of time to be built?
> 
> The Salsa CI team needs to reintroduce the ccache support, that would
> probably be useful here.

It would reduce the average build time, but would (slightly) increase
the worst-case build time so would not solve this problem.

The current maximum of 3 hours is already an absurdly long time to wait
for CI.  The solution for slow CI builds has to be some combination of:

- Build less
  - Disable debug info
  - Use a build profile for CI that builds a representative subset
- Build smarter
  - Don't run tests as part of the build that can be deferred to
    autopkgtest.  (They should still run by default, just not in CI
    which will run autopkgtest immediately afterwards.)
  - Replace the full build job with build-any and build-all jobs.
    (This would require a bit more customisation of the pipeline.)
  - Make more of the build run in parallel
- Use faster runners

Ben.

> In the meantime, please reach out to the salsa
> admins to see if they could help.
> 
> Cheers,
> 
>  -- S

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken
signature.asc (application/pgp-signature, 833 B)