v0.7.1 packaged fixed the docker-dev build.
D4715 fixed the icinga plugins build.

I updated the configuration documentation about ^ btw [1]

I got a full build from commit with ^ then tag to pypi module builds and debian package builds ok (both stable and unstable now)

This is probably mostly deprecated now we have mypy & al. Also the reporting via warnings-ng-plugin may not be such a priority now.

Fixed in https://forge.softwareheritage.org/rDGRPHcd135e6607350710ec5b3403b19a92c1d5a28cf5 and https://forge.softwareheritage.org/rDGRPH164bf7b1464ea3b9eb38c91c2a7caee7d6b149f7

Another simple way to reproduce is just removing the *.jar file and running pytest on test_api_client.py.
This is not even a Java exception, but chances are fixing that case will fix at least a significant part of the general problem, if not all.

AFAICT this is a more general problem, the Java backend can hang forever in case of unexpected situations (uncaught exceptions? I really don't know…), which will make it not respond to any incoming request with no visible output.
We should make this visible and debuggable.

$kitchen_sink++

I've been wondering about this for a while too. The only use case for having red/green on every commit is that it might help people who bisect a repo, and it's certainly not worth the downsides that much.

+1 on this.

closing this, as we have "proper" CI since quite a while now (it could always be improved of course, but no need to keep the meta task open at this point)

The .jar file is never installed within the tox environment, so the graph backend process fixture never actually succeeds in launching the server. FWIW, when running tox on my system, the tests hang just the same.

I've rebased the jdk11 image on top of buster using the awful, awful a3776d744f. This means python 3.7 by default, and it looks like swh.graph CI works.

I've definitely got a "build failed" automatic notification after a push I did a while ago. I think it was on swh-environment, before we (recently) disabled the CI on it. If this notification behavior is not uniform across repos, we should make it so.

In T2012#37261, @zack wrote:

Count me as -1 on this.

Strict rules like these tend to get in the way of getting work done when you need it.

From what you wrote, what I think will actually fix your problem is seeing the OK/KO CI marker in the list of pending review requests, so that you can just skip the ones with failing build without having to click them. Would that be enough?

I totally agree that we need safeguards against pushing stuff that breaks CI, but we seem to have plenty already: we use code review thoroughly, and that triggers CI;

Count me as -1 on this.