| Message ID | 20200915193832.291674-1-arnout@mind.be |
|---|---|
| State | Rejected |
| Headers | show |
| Series | support/misc/gitlab-ci.yml.in: specify image to use | expand |
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. >
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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.
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
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.
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(+)