[Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Romain Naour]

Currently when a tag is added to the Buildroot git tree, the gitlab-ci
create a pipeline with several hundred of jobs (~750) to build all
defconfigs and execute the Buildroot testsuite.

However, there is only a limited number of gitlab-ci runner (9 runners)
and some jobs reach the timeout limit (24h) while waiting for a runner
[1]. Indeed, the Buildroot project doesn't use the Gitlab's shared
runners.

In addition to the pipeline created when a new tag is added to the
git repository, two pipelines are created each weeks to execute the
Buildroot testsuite (on monday [2]) and build all defconfigs (on
Thursday [3]).

At some point there are too many jobs waiting in gitlab due board
defconfigs builds. Indded a board defconfig requires a lot of time
(~30min) compared to other jobs in order to build a toolchain and a
kernel linux along with a basic rootfs. There is currently 262
defconfigs.

This is even worse when several pipelines are trigged at the same
time (new git tag and scheduled pipeline trigger).

In order to reduce the number of long jobs, don't build board
defconfigs with pipelines trigged on tag, keeping only the runtime
tests and the Qemu's defconfigs.

[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/1758966541
[2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/404035190
[3] https://gitlab.com/buildroot.org/buildroot/-/pipelines/401685550

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
v2: improve commit log

I would like to keep Qemu runtime testing when a tag is added because
it test the toolchain provided by default by Buildroot on several
architectures.
---
 support/scripts/generate-gitlab-ci-yml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/support/scripts/generate-gitlab-ci-yml b/support/scripts/generate-gitlab-ci-yml
index 7d09279bbd..232785f2e3 100755
--- a/support/scripts/generate-gitlab-ci-yml
+++ b/support/scripts/generate-gitlab-ci-yml
@@ -36,6 +36,9 @@ gen_tests() {
              )
 
     if [ -n "${CI_COMMIT_TAG}" ]; then
+        # When a tag is added to the Buildroot git tree, we want
+        # to run the runtime tests and only test Qemu defconfigs.
+        defconfigs=( $(cd configs; LC_ALL=C ls -1 qemu_*_defconfig) )
         do_basics=true
         do_defconfigs=base
         do_runtime=true
-- 
2.31.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Yann E. MORIN]

Romain, All,

+Arnout

On 2021-11-09 23:03 +0100, Romain Naour spake thusly:
> Currently when a tag is added to the Buildroot git tree, the gitlab-ci
> create a pipeline with several hundred of jobs (~750) to build all
> defconfigs and execute the Buildroot testsuite.
> 
> However, there is only a limited number of gitlab-ci runner (9 runners)
> and some jobs reach the timeout limit (24h) while waiting for a runner
> [1]. Indeed, the Buildroot project doesn't use the Gitlab's shared
> runners.
> 
> In addition to the pipeline created when a new tag is added to the
> git repository, two pipelines are created each weeks to execute the
> Buildroot testsuite (on monday [2]) and build all defconfigs (on
> Thursday [3]).
> 
> At some point there are too many jobs waiting in gitlab due board
> defconfigs builds. Indded a board defconfig requires a lot of time
> (~30min) compared to other jobs in order to build a toolchain and a
> kernel linux along with a basic rootfs. There is currently 262
> defconfigs.
> 
> This is even worse when several pipelines are trigged at the same
> time (new git tag and scheduled pipeline trigger).
> 
> In order to reduce the number of long jobs, don't build board
> defconfigs with pipelines trigged on tag, keeping only the runtime
> tests and the Qemu's defconfigs.
> 
> [1] https://gitlab.com/buildroot.org/buildroot/-/jobs/1758966541
> [2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/404035190
> [3] https://gitlab.com/buildroot.org/buildroot/-/pipelines/401685550
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Arnout Vandecappelle <arnout@mind.be>

Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>

If noone whines shortly, I'll apply it.

Regards,
Yann E. MORIN.

> ---
> v2: improve commit log
> 
> I would like to keep Qemu runtime testing when a tag is added because
> it test the toolchain provided by default by Buildroot on several
> architectures.
> ---
>  support/scripts/generate-gitlab-ci-yml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/support/scripts/generate-gitlab-ci-yml b/support/scripts/generate-gitlab-ci-yml
> index 7d09279bbd..232785f2e3 100755
> --- a/support/scripts/generate-gitlab-ci-yml
> +++ b/support/scripts/generate-gitlab-ci-yml
> @@ -36,6 +36,9 @@ gen_tests() {
>               )
>  
>      if [ -n "${CI_COMMIT_TAG}" ]; then
> +        # When a tag is added to the Buildroot git tree, we want
> +        # to run the runtime tests and only test Qemu defconfigs.
> +        defconfigs=( $(cd configs; LC_ALL=C ls -1 qemu_*_defconfig) )
>          do_basics=true
>          do_defconfigs=base
>          do_runtime=true
> -- 
> 2.31.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Yann E. MORIN]

Romain, All,

On 2021-11-09 23:03 +0100, Romain Naour spake thusly:
> Currently when a tag is added to the Buildroot git tree, the gitlab-ci
> create a pipeline with several hundred of jobs (~750) to build all
> defconfigs and execute the Buildroot testsuite.
> 
> However, there is only a limited number of gitlab-ci runner (9 runners)
> and some jobs reach the timeout limit (24h) while waiting for a runner
> [1]. Indeed, the Buildroot project doesn't use the Gitlab's shared
> runners.
> 
> In addition to the pipeline created when a new tag is added to the
> git repository, two pipelines are created each weeks to execute the
> Buildroot testsuite (on monday [2]) and build all defconfigs (on
> Thursday [3]).
> 
> At some point there are too many jobs waiting in gitlab due board
> defconfigs builds. Indded a board defconfig requires a lot of time
> (~30min) compared to other jobs in order to build a toolchain and a
> kernel linux along with a basic rootfs. There is currently 262
> defconfigs.
> 
> This is even worse when several pipelines are trigged at the same
> time (new git tag and scheduled pipeline trigger).
> 
> In order to reduce the number of long jobs, don't build board
> defconfigs with pipelines trigged on tag, keeping only the runtime
> tests and the Qemu's defconfigs.
> 
> [1] https://gitlab.com/buildroot.org/buildroot/-/jobs/1758966541
> [2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/404035190
> [3] https://gitlab.com/buildroot.org/buildroot/-/pipelines/401685550
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Arnout Vandecappelle <arnout@mind.be>

Applied to master, thanks.

Regards,
Yann E. MORIN.

> ---
> v2: improve commit log
> 
> I would like to keep Qemu runtime testing when a tag is added because
> it test the toolchain provided by default by Buildroot on several
> architectures.
> ---
>  support/scripts/generate-gitlab-ci-yml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/support/scripts/generate-gitlab-ci-yml b/support/scripts/generate-gitlab-ci-yml
> index 7d09279bbd..232785f2e3 100755
> --- a/support/scripts/generate-gitlab-ci-yml
> +++ b/support/scripts/generate-gitlab-ci-yml
> @@ -36,6 +36,9 @@ gen_tests() {
>               )
>  
>      if [ -n "${CI_COMMIT_TAG}" ]; then
> +        # When a tag is added to the Buildroot git tree, we want
> +        # to run the runtime tests and only test Qemu defconfigs.
> +        defconfigs=( $(cd configs; LC_ALL=C ls -1 qemu_*_defconfig) )
>          do_basics=true
>          do_defconfigs=base
>          do_runtime=true
> -- 
> 2.31.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Thomas Petazzoni]

Hello,

On Thu, 11 Nov 2021 09:25:48 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> On 2021-11-09 23:03 +0100, Romain Naour spake thusly:
> > Currently when a tag is added to the Buildroot git tree, the gitlab-ci
> > create a pipeline with several hundred of jobs (~750) to build all
> > defconfigs and execute the Buildroot testsuite.
> > 
> > However, there is only a limited number of gitlab-ci runner (9 runners)
> > and some jobs reach the timeout limit (24h) while waiting for a runner
> > [1]. Indeed, the Buildroot project doesn't use the Gitlab's shared
> > runners.
> > 
> > In addition to the pipeline created when a new tag is added to the
> > git repository, two pipelines are created each weeks to execute the
> > Buildroot testsuite (on monday [2]) and build all defconfigs (on
> > Thursday [3]).
> > 
> > At some point there are too many jobs waiting in gitlab due board
> > defconfigs builds. Indded a board defconfig requires a lot of time
> > (~30min) compared to other jobs in order to build a toolchain and a
> > kernel linux along with a basic rootfs. There is currently 262
> > defconfigs.
> > 
> > This is even worse when several pipelines are trigged at the same
> > time (new git tag and scheduled pipeline trigger).
> > 
> > In order to reduce the number of long jobs, don't build board
> > defconfigs with pipelines trigged on tag, keeping only the runtime
> > tests and the Qemu's defconfigs.
> > 
> > [1] https://gitlab.com/buildroot.org/buildroot/-/jobs/1758966541
> > [2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/404035190
> > [3] https://gitlab.com/buildroot.org/buildroot/-/pipelines/401685550
> > 
> > Signed-off-by: Romain Naour <romain.naour@gmail.com>
> > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> > Cc: Arnout Vandecappelle <arnout@mind.be>  
> 
> Applied to master, thanks.

I hadn't had the chance to chime in on this one, but I don't entirely
agree with the change (I also don't entirely disagree!). Indeed, I
believe we do want to have the results of the defconfigs builds on
tags. If we missed something, and one of our release has defconfigs
broken, we definitely want to know it and fix it.

This disabling of defconfig builds is only done because there is an
infrastructure issue. But really, from a proper QA/CI point of view, we
really want to build the defconfigs on tags I think.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Yann E. MORIN]

Thomas, All,

On 2021-11-11 11:02 +0100, Thomas Petazzoni spake thusly:
> On Thu, 11 Nov 2021 09:25:48 +0100
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > On 2021-11-09 23:03 +0100, Romain Naour spake thusly:
> > > In order to reduce the number of long jobs, don't build board
> > > defconfigs with pipelines trigged on tag, keeping only the runtime
> > > tests and the Qemu's defconfigs.
> > Applied to master, thanks.
> I hadn't had the chance to chime in on this one,

Sorry, I could have waited a bit more indeed...

> but I don't entirely
> agree with the change (I also don't entirely disagree!). Indeed, I
> believe we do want to have the results of the defconfigs builds on
> tags. If we missed something, and one of our release has defconfigs
> broken, we definitely want to know it and fix it.

On principle, I do agree with that, and that's what I initially coded in
that script.

> This disabling of defconfig builds is only done because there is an
> infrastructure issue. But really, from a proper QA/CI point of view, we
> really want to build the defconfigs on tags I think.

Again, agreed on principle.

But as Romain explained, that creates too much jobs when a tag is cut,
so much so that a lot of them do not even stand a chance to even start.

In that case, the CI is not usefull at all either.

On the other hand, the defconfigs are already built reasonably often,
every week, with a scheduled pipeline. It is thus pretty quick to notice
a build failure.

So, my opinion is that I prefer a partial CI that is stable and
dependable, where each failure is an actual failure, rather than a
full-range CI that has a very low SNR, where people eventually stop
caring about failure reports because they are often spurious failures.

Of course, we can reverse course on that commit; after all, that's what
git-revert is for! ;-)

The better course of action, obviously, would be to have an infra that
is strong enough to absorb all that load when we push a tag, but that's
an order of magnitude more complex to achieve.

One thing, though: maybe some of the runners could be configured to
accept more jobs at once, so even if each job then takes longer to run,
we start them faster and thus do not hit the 24-hour blockage limit.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Romain Naour]

Hello Thomas, Yann, All,

Le 11/11/2021 à 11:15, Yann E. MORIN a écrit :
> Thomas, All,
> 
> On 2021-11-11 11:02 +0100, Thomas Petazzoni spake thusly:
>> On Thu, 11 Nov 2021 09:25:48 +0100
>> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>>> On 2021-11-09 23:03 +0100, Romain Naour spake thusly:
>>>> In order to reduce the number of long jobs, don't build board
>>>> defconfigs with pipelines trigged on tag, keeping only the runtime
>>>> tests and the Qemu's defconfigs.
>>> Applied to master, thanks.
>> I hadn't had the chance to chime in on this one,
> 
> Sorry, I could have waited a bit more indeed...
> 
>> but I don't entirely
>> agree with the change (I also don't entirely disagree!). Indeed, I
>> believe we do want to have the results of the defconfigs builds on
>> tags. If we missed something, and one of our release has defconfigs
>> broken, we definitely want to know it and fix it.
> 
> On principle, I do agree with that, and that's what I initially coded in
> that script.
> 
>> This disabling of defconfig builds is only done because there is an
>> infrastructure issue. But really, from a proper QA/CI point of view, we
>> really want to build the defconfigs on tags I think.
> 
> Again, agreed on principle.

Indeed, Ideally defconfigs should be tested on release.

But each defconfig spend most of the time to build the internal toolchain maybe
another solution is to use an prebuilt toolchain. Still building a kernel takes
some time.

Since most of defconfigs jobs are executed before the testsuite jobs, it delay
too much the testsuite results.

> 
> But as Romain explained, that creates too much jobs when a tag is cut,
> so much so that a lot of them do not even stand a chance to even start.

See again what happened yesterday when Peter did two Buildroot releases at the
same time (2021.02.7 and 2021.08.2). The pipeline for the LTS 2021.02.7 didn't
even started yet and will probably reach the 24h timeout.

> 
> In that case, the CI is not usefull at all either.
> 
> On the other hand, the defconfigs are already built reasonably often,
> every week, with a scheduled pipeline. It is thus pretty quick to notice
> a build failure.
> 
> So, my opinion is that I prefer a partial CI that is stable and
> dependable, where each failure is an actual failure, rather than a
> full-range CI that has a very low SNR, where people eventually stop
> caring about failure reports because they are often spurious failures.

Since I care about the gitlab-ci, I restarted a lot of jobs that failed due to
timeout but this is an annoying work...

> 
> Of course, we can reverse course on that commit; after all, that's what
> git-revert is for! ;-)

I would be happy to revert this patch :)

> 
> The better course of action, obviously, would be to have an infra that
> is strong enough to absorb all that load when we push a tag, but that's
> an order of magnitude more complex to achieve.
> 
> One thing, though: maybe some of the runners could be configured to
> accept more jobs at once, so even if each job then takes longer to run,
> we start them faster and thus do not hit the 24-hour blockage limit.

I'm not sure if this solution can scale. We still add some new board defconfig :)

Best regards,
Romain


> 
> Regards,
> Yann E. MORIN.
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Thomas Petazzoni]

Hello,

On Thu, 11 Nov 2021 11:15:56 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> > I hadn't had the chance to chime in on this one,  
> 
> Sorry, I could have waited a bit more indeed...

No, no, I think it's good that code gets reviewed and merged quickly.
We can't wait on every patch for everyone's opinion, otherwise the
project wouldn't move at all. So I really have absolutely nothing
against the fact of merging patches quickly.

> Again, agreed on principle.
> 
> But as Romain explained, that creates too much jobs when a tag is cut,
> so much so that a lot of them do not even stand a chance to even start.
> 
> In that case, the CI is not usefull at all either.
> 
> On the other hand, the defconfigs are already built reasonably often,
> every week, with a scheduled pipeline. It is thus pretty quick to notice
> a build failure.

True.

> So, my opinion is that I prefer a partial CI that is stable and
> dependable, where each failure is an actual failure, rather than a
> full-range CI that has a very low SNR, where people eventually stop
> caring about failure reports because they are often spurious failures.
> 
> Of course, we can reverse course on that commit; after all, that's what
> git-revert is for! ;-)
> 
> The better course of action, obviously, would be to have an infra that
> is strong enough to absorb all that load when we push a tag, but that's
> an order of magnitude more complex to achieve.

Indeed, I think we both agree that we should ideally be able to build
defconfigs every time a tag is pushed, and it's only a
practical/pragmatic reason that leads us to not do that. Fair enough.

> One thing, though: maybe some of the runners could be configured to
> accept more jobs at once, so even if each job then takes longer to run,
> we start them faster and thus do not hit the 24-hour blockage limit.

Things get really really slow if you build too many jobs in parallel,
as the runners start swapping like crazy.

So all in all, I'd say Romain's patch is OK, even though I wish we
could do better. That being said, when the tag is pushed it's a bit too
"late" to fixup defconfigs: they should ideally build properly *before*
a tag is created/pushed.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Arnout Vandecappelle]

On 09/11/2021 23:03, Romain Naour wrote:
> |Currently when a tag is added to the Buildroot git tree, the gitlab-ci create a 
> pipeline with several hundred of jobs (~750) to build all defconfigs and execute 
> the Buildroot testsuite.|

  Note that gitlab also has a *hard* limit of 1000 jobs per pipeline. Since we 
continuously add runtime tests and defconfigs, we're going to hit that limit at 
some point.

  So it's not simply an infrastructure issue, I'd say.

  That said: a hack to bypass that limit is to trigger several sub-pipelines 
instead of just a single one, e.g. one for defconfigs and one for runtime tests.

  Regards,
  Arnout
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

[Peter Korsgaard]

>>>>> "Romain" == Romain Naour <romain.naour@gmail.com> writes:

 > Currently when a tag is added to the Buildroot git tree, the gitlab-ci
 > create a pipeline with several hundred of jobs (~750) to build all
 > defconfigs and execute the Buildroot testsuite.

 > However, there is only a limited number of gitlab-ci runner (9 runners)
 > and some jobs reach the timeout limit (24h) while waiting for a runner
 > [1]. Indeed, the Buildroot project doesn't use the Gitlab's shared
 > runners.

 > In addition to the pipeline created when a new tag is added to the
 > git repository, two pipelines are created each weeks to execute the
 > Buildroot testsuite (on monday [2]) and build all defconfigs (on
 > Thursday [3]).

 > At some point there are too many jobs waiting in gitlab due board
 > defconfigs builds. Indded a board defconfig requires a lot of time
 > (~30min) compared to other jobs in order to build a toolchain and a
 > kernel linux along with a basic rootfs. There is currently 262
 > defconfigs.

 > This is even worse when several pipelines are trigged at the same
 > time (new git tag and scheduled pipeline trigger).

 > In order to reduce the number of long jobs, don't build board
 > defconfigs with pipelines trigged on tag, keeping only the runtime
 > tests and the Qemu's defconfigs.

 > [1] https://gitlab.com/buildroot.org/buildroot/-/jobs/1758966541
 > [2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/404035190
 > [3] https://gitlab.com/buildroot.org/buildroot/-/pipelines/401685550

 > Signed-off-by: Romain Naour <romain.naour@gmail.com>
 > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
 > Cc: Yann E. MORIN <yann.morin.1998@free.fr>
 > Cc: Arnout Vandecappelle <arnout@mind.be>
 > ---
 > v2: improve commit log

 > I would like to keep Qemu runtime testing when a tag is added because
 > it test the toolchain provided by default by Buildroot on several
 > architectures.

Committed to 2021.02.x and 2021.08.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot