Hi Reinhard,
> The consistent OOM is surprising given that you state that the worker
> has 250GB of RAM. Looking at the logs,
> I note that the tests are being passed the option -p 160 by the
> dh-golang helper, so it will build
> and run test executables concurrently. That confirms to me that we are
> indeed running on these 250GB/160 core workers.
We only have one armhf host, so *all* armhf tests are run there. I'm
also not seeing this problem back in the logs:
https://ci.debian.net/munin/ci-worker-armel-01/ci-worker-armel-01/memory.html.
But maybe the incident is too short to be caught by the once per 5
minutes poll.
> Is it possible that armhf is setting up ulimits that limits the amountSure, I've cobbled up https://salsa.debian.org/ci-team/autodep8/-/merge_requests/25 for this.
> of memory the test may allocate?
root@ci-worker-armel-01:~# ulimit
unlimited
> As far as I understand, all golang packages use autodep8 to declare the
> tests,
> which doesn't support adding the Architecture field.
I think you're right, but maybe we should fix autodep8 to enable the
change like the other overwrites in section `PACKAGE-SPECIFIC
CONFIGURATION` of $(man autodep8).
> In order to get
> around this,
> I guess I could remove the Testsuite field from debian/control and add a
> debian/tests/control that looks similar to what autodep8 generates, but adds
> the Architecture: !armhf restriction.
Maybe until autodep8 is fixed? I fear that this may cause future trouble
if/when autodep8 support for golang gets updated.