[Buildroot] [PATCH] support/misc/gitlab-ci.yml.in: specify image to use

[Buildroot] [PATCH] support/misc/gitlab-ci.yml.in: specify image to use

[Arnout Vandecappelle]

Commit 93a2870966 split off the generated gitlab-ci.yml into a child
pipeline. However, the generated gitlab-ci.yml file no longer had an
'image' tag. The result is that the jobs will use whatever image happens
to be configured on the runner - which leads to frequent pipeline
failures.

Fix this by explicitly specifying the image to use (the same one as in
top-level .gitlab-ci.yml).

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 support/misc/gitlab-ci.yml.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/support/misc/gitlab-ci.yml.in b/support/misc/gitlab-ci.yml.in
index fcfff5c6aa..892eb9ed64 100644
--- a/support/misc/gitlab-ci.yml.in
+++ b/support/misc/gitlab-ci.yml.in
@@ -1,3 +1,5 @@
+image: buildroot/base:20200814.2228
+
 .check-DEVELOPERS_base:
     # get-developers should print just "No action specified"; if it prints
     # anything else, it's a parse error.
-- 
2.26.2

[Buildroot] [PATCH] support/misc/gitlab-ci.yml.in: specify image to use

[Romain Naour]

Hello Arnout,

Le 15/09/2020 ? 21:38, Arnout Vandecappelle (Essensium/Mind) a ?crit?:
> Commit 93a2870966 split off the generated gitlab-ci.yml into a child
> pipeline. However, the generated gitlab-ci.yml file no longer had an
> 'image' tag. The result is that the jobs will use whatever image happens
> to be configured on the runner - which leads to frequent pipeline
> failures.
> 
> Fix this by explicitly specifying the image to use (the same one as in
> top-level .gitlab-ci.yml).
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  support/misc/gitlab-ci.yml.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/support/misc/gitlab-ci.yml.in b/support/misc/gitlab-ci.yml.in
> index fcfff5c6aa..892eb9ed64 100644
> --- a/support/misc/gitlab-ci.yml.in
> +++ b/support/misc/gitlab-ci.yml.in
> @@ -1,3 +1,5 @@
> +image: buildroot/base:20200814.2228
> +

Adding Yann in Cc:

This basically revert change from:

https://git.buildroot.net/buildroot/commit/?id=bef67390949dd6ba5cbfd658371c5df81bb5758c

commit 93a2870966 didn't remove the 'image' tag.

I guess you used support/scripts/generate-gitlab-ci-yml locally without gilab
environment variable (CI_JOB_IMAGE).

Best regards,
Romain


>  .check-DEVELOPERS_base:
>      # get-developers should print just "No action specified"; if it prints
>      # anything else, it's a parse error.
> 

[Buildroot] [PATCH] support/misc/gitlab-ci.yml.in: specify image to use

[Yann E. MORIN]

Arnout, All,

On 2020-09-15 21:38 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
> Commit 93a2870966 split off the generated gitlab-ci.yml into a child
> pipeline. However, the generated gitlab-ci.yml file no longer had an
> 'image' tag.

Commit 93a2870966 still kept the image tag in the template. The removal
of the iamge tag was done later, see below...

> The result is that the jobs will use whatever image happens
> to be configured on the runner - which leads to frequent pipeline
> failures.

Do you have an example of such a pipeline (and its parent)?

> Fix this by explicitly specifying the image to use (the same one as in
> top-level .gitlab-ci.yml).

I was the one to explicitly remove it, because it is now supposed to be
added bny the script, with commit bef6739094 (gitlab-ci: share the image
version with the child):

    +preamble() {
    +    local template="${1}"
    +
    +    cat - "${template}" <<-_EOF_
    +       # This file is generated; do not edit!
    +       # Builds appear on https://gitlab.com/buildroot.org/buildroot/pipelines
    +
    +       image: ${CI_JOB_IMAGE}
    +
    +_EOF_
    +}

So the preamble is supposed to now contain the image name, the the
template.

And indeed it works for me:

    $ CI_JOB_IMAGE=FOOO support/scripts/generate-gitlab-ci-yml \
        support/misc/gitlab-ci.yml.in
    [...]
    image: FOOO
    [...]

And it looks like the tests I had done were also successfull:

    https://gitlab.com/ymorin/buildroot/-/pipelines/186530918
    https://gitlab.com/ymorin/buildroot/-/jobs/723345502
    https://gitlab.com/ymorin/buildroot/-/jobs/723345502/artifacts/file/generated-gitlab-ci.yml
     -> image: buildroot/base:20200814.2228

And so the jobs in the child pipeline use the expected image:

    https://gitlab.com/ymorin/buildroot/-/pipelines/186531247
    https://gitlab.com/ymorin/buildroot/-/jobs/723346533
     -> Using Docker executor with image buildroot/base:20200814.2228 ...

So, I'm not in favour of restoring the hard-coded version in the child
pipeline.

Regards,
Yann E. MORIN.

> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
>  support/misc/gitlab-ci.yml.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/support/misc/gitlab-ci.yml.in b/support/misc/gitlab-ci.yml.in
> index fcfff5c6aa..892eb9ed64 100644
> --- a/support/misc/gitlab-ci.yml.in
> +++ b/support/misc/gitlab-ci.yml.in
> @@ -1,3 +1,5 @@
> +image: buildroot/base:20200814.2228
> +
>  .check-DEVELOPERS_base:
>      # get-developers should print just "No action specified"; if it prints
>      # anything else, it's a parse error.
> -- 
> 2.26.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/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] [PATCH] support/misc/gitlab-ci.yml.in: specify image to use

[Yann E. MORIN]

Arnout, All,

On 2020-09-15 21:50 +0200, Yann E. MORIN spake thusly:
> On 2020-09-15 21:38 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
> > Commit 93a2870966 split off the generated gitlab-ci.yml into a child
> > pipeline. However, the generated gitlab-ci.yml file no longer had an
> > 'image' tag.
> Commit 93a2870966 still kept the image tag in the template. The removal
> of the iamge tag was done later, see below...
> > The result is that the jobs will use whatever image happens
> > to be configured on the runner - which leads to frequent pipeline
> > failures.
> Do you have an example of such a pipeline (and its parent)?

Ah, I see some, indeed:

    https://gitlab.com/buildroot.org/buildroot/-/pipelines/189823194

What is interesting here, is that the generate-gitlab-ci-yml job ran on
your runner:

    https://gitlab.com/buildroot.org/buildroot/-/jobs/737264806

    Running with gitlab-runner 12.6.0 (ac8e767a)
      on Buildroot-mind fMZePpyU

While a working pipeline was running on another runner:

    https://gitlab.com/buildroot.org/buildroot/-/pipelines/190372488
    https://gitlab.com/buildroot.org/buildroot/-/jobs/739712931

    Running with gitlab-runner 13.0.0 (c127439c)
      on gcc160 f0ab0d82

And my tests were also using a more recent runner version:

    https://gitlab.com/ymorin/buildroot/-/pipelines/186530918
    https://gitlab.com/ymorin/buildroot/-/jobs/723345502

    Running with gitlab-runner 13.3.1 (738bbe5a)
      on docker-auto-scale ed2dce3a

So it seems that the 12.6.0 runner version is too old to export the
CI_JOB_IMAGE variable, and that 13.0.0 and up are OK.

Could you update your runner, maybe?

And we should also probably be using the same version on all our
runners, maybe...

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] [PATCH] support/misc/gitlab-ci.yml.in: specify image to use

[Arnout Vandecappelle]

On 16/09/2020 08:32, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2020-09-15 21:50 +0200, Yann E. MORIN spake thusly:
>> On 2020-09-15 21:38 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
>>> Commit 93a2870966 split off the generated gitlab-ci.yml into a child
>>> pipeline. However, the generated gitlab-ci.yml file no longer had an
>>> 'image' tag.
>> Commit 93a2870966 still kept the image tag in the template. The removal
>> of the iamge tag was done later, see below...

 Darn, I shouldn't be doing this quick-quick stuff...

>>> The result is that the jobs will use whatever image happens
>>> to be configured on the runner - which leads to frequent pipeline
>>> failures.
>> Do you have an example of such a pipeline (and its parent)?
> 
> Ah, I see some, indeed:
> 
>     https://gitlab.com/buildroot.org/buildroot/-/pipelines/189823194
> 
> What is interesting here, is that the generate-gitlab-ci-yml job ran on
> your runner:
> 
>     https://gitlab.com/buildroot.org/buildroot/-/jobs/737264806
> 
>     Running with gitlab-runner 12.6.0 (ac8e767a)
>       on Buildroot-mind fMZePpyU
> 
> While a working pipeline was running on another runner:
> 
>     https://gitlab.com/buildroot.org/buildroot/-/pipelines/190372488
>     https://gitlab.com/buildroot.org/buildroot/-/jobs/739712931
> 
>     Running with gitlab-runner 13.0.0 (c127439c)
>       on gcc160 f0ab0d82
> 
> And my tests were also using a more recent runner version:
> 
>     https://gitlab.com/ymorin/buildroot/-/pipelines/186530918
>     https://gitlab.com/ymorin/buildroot/-/jobs/723345502
> 
>     Running with gitlab-runner 13.3.1 (738bbe5a)
>       on docker-auto-scale ed2dce3a
> 
> So it seems that the 12.6.0 runner version is too old to export the
> CI_JOB_IMAGE variable, and that 13.0.0 and up are OK.
> 
> Could you update your runner, maybe?

 Thank you for your investigation! I've updated the runner and marked this patch
as rejected. Let's see how this goes.


> And we should also probably be using the same version on all our
> runners, maybe...

 Really, gitlab should give a warning if a runner is too old...

 Regards,
 Arnout