[Buildroot] [PATCH 04/14 v4] package/skeleton: split out into skeleton-custom
Ricardo Martincoski
ricardo.martincoski at gmail.com
Fri Jul 28 03:02:34 UTC 2017
Hello,
On Wed, Jul 26, 2017 at 08:49 AM, Arnout Vandecappelle wrote:
> On 26-07-17 02:16, Arnout Vandecappelle wrote:
>> I've fixed all that and was going to apply, but then I noticed that patch 1
>> breaks our tests, so I refrained from pushing it. You can fetch it from
>> https://gitlab.com/arnout/buildroot (master branch; will be rebased away in a
>> couple of days).
>
> So I pushed this commit with the runtime testing patch 11 on top of to gitlab
> to see what would happen, and the systemd test fails. It seems the getty on
> ttyAMA0 can't be started. Is that to be expected, due to the /var/log->/tmp symlink?
>
> You can inspect the output on [1], but it's not saying much.
It seems a timeout while waiting for the login prompt.
> [1]
> https://gitlab.com/arnout/buildroot/-/jobs/24489865/artifacts/raw/test-output/TestInitSystemSystemdRwFull-run.log
This test you triggered ran on the runner e11ae361.
I borrowed your commit (e8e38e9e) and did some tests.
I got lucky and the test I triggered ran on the shared runner 4e4528ca and
passed [2].
Then I retriggered it to run on my private runner, while I was also running
a resource intensive task (actually I was running the same test in the same
commit locally with the default -j 0) and the test in the runner failed [3]
(while the local test passed).
[2] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25090126
[3] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25101360
TestIPythonPy3 for instance seems to be have tidy timeout for math_floor_test.
Its first execution [4] ran in the (free, as in free beer!) elastic runner from
gitlab and failed. The second execution [5] ran in my private runner (a docker
in my personal computer) and passed.
[4] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25090131
[5] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25099593
Concerning the test infra (I say that including gitlab) we should choose a path
to follow:
1) Use private runners
2) Adapt timeouts when a test sporadically fails and keep using the gitlab
runners ([6] shows that we already use them)
[6] https://gitlab.com/buildroot.org/buildroot/-/jobs/24184768
I would go with option 2. We are not doing CI for now, so sporadic failures are
not a big concern IMO.
Regards,
Ricardo
More information about the buildroot
mailing list