[Buildroot] [PATCH 04/14 v4] package/skeleton: split out into skeleton-custom
thomas.petazzoni at free-electrons.com
Fri Jul 28 06:18:34 UTC 2017
On Fri, 28 Jul 2017 00:02:34 -0300, Ricardo Martincoski wrote:
> 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 .
> 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 
> (while the local test passed).
>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25090126
>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25101360
> TestIPythonPy3 for instance seems to be have tidy timeout for math_floor_test.
> Its first execution  ran in the (free, as in free beer!) elastic runner from
> gitlab and failed. The second execution  ran in my private runner (a docker
> in my personal computer) and passed.
>  https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/25090131
>  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
So it is possible to "contribute" as a private runner for your own CI
projects hosted on the public Gitlab ?
> 2) Adapt timeouts when a test sporadically fails and keep using the gitlab
> runners ( shows that we already use them)
>  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.
The idea of using Gitlab is (amongst other things) to leverage the
public runners. That being said, sporadic failures are really not nice,
because they always cause confusion.
Why don't we significantly increase the timeout, like to several
minutes? In most cases, the test will be successful, and the expected
output will arrive in a few seconds. It's only when there is a real
problem in the test that we will hit the timeout, but in this case,
having the test take a few more minutes is not a big deal.
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
More information about the buildroot