CI pipeline timeout
It looks like the Lintian autopkgtests take too long to run most of the
time, which is making it fairly hard to handle merge requests since the
pipeline fails. The project timeout was already set to 1d but the
autopkgtests job is timing out after one hour, so I assume that this is a
runner timeout that we can't increase.
Or... hm. I just realized that Salsa shows the pipeline as running on the
project of the MR submitter. Maybe the problem is that it's using their
timeout and not ours? That still poses roughly the same problem, though.
This seems to be the only CI job that runs the test suite, so clearly we
need it to confirm that MRs haven't broken anything.
I'm wondering what the options are here. Maybe we can break the test
suite up into multiple parts that can run separately? That will take as
long but should avoid the timeout.
Obviously ideal would be to speed up testing. It looks like just building
all of the test packages takes a half-hour, and then running Lintian on
all of them takes longer than that, at least some of the time. We do
build a *lot* of test packages (1,437), but of course it's nice to have
one test package per conceptual test and not to have to think about
merging multiple tests together into a single package.
I'm also a bit lost in the source code trying to figure out where the test
packages are built to see if we could make that faster, but that's about a
second per test package, not too bad, so I'm not sure how much leeway
there is.
If this were GitHub Actions, I'd be tempted to try to cache all of the
test packages and only rebuild them if something has changed, which I
suspect would save some time. I'm not sure how to do that with GitLab.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: