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 ([email protected]) <https://www.eyrie.org/~eagle/>
