On Tue, Jul 12, 2022 at 4:17 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jeff King <peff@xxxxxxxx> writes: > > >> 512 is probably OK in CI in an isolated environment but is too low on a > >> typical "What you mean I'm not working? I'm waiting for the test run!" > >> developper workstation. > >> > >> Conversely, which number would be too high to catch what the test is > >> supposed to catch? Does it incur a big performance penalty to go as high > >> as possible? > > > > This bit me, too. It works if I run it standalone: > > > > $ ./t5330-no-lazy-fetch-with-commit-graph.sh > > ok 1 - setup: prepare a repository with a commit > > ok 2 - setup: prepare a repository with commit-graph contains the commit > > ok 3 - setup: change the alternates to what without the commit > > ok 4 - fetch any commit from promisor with the usage of the commit graph > > # passed all 4 test(s) > > > > but it fails when I run the whole test suite with "prove -j32". Or even > > easier, just run it under "--stress": > > Understandable. I am usually on a datacentre VM without graphical > UI so the process count there is much lower than on a typical > developer workstation. > > I wonder if we can just run the test without any limit? If in an > unattended CI situation, hopefully they will kick the job out due to > quota, and on a developer workstation, there may be processes killed > left and right, but that is only when the "infinite respawning" bug > reappears. > The tricky thing about using ulimit is that it's tied to the entire development station. I have tried to run the test without any limit [1], it did finally be canceled after 6 hours. Remove the "ulimit", once the infinite loop reappears, this test seems like a bomb to developers that quickly consumes all resources? While "1024" works fine with "--stress" , there are reasons to wonder if it's enough, or maybe we can take a value like 10240 that we wouldn't normally reach? 1. https://github.com/chiyutianyi/git/runs/6962635320 Thanks -Han Xin
