[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 1/4] Jobs based on custom runners: documentation and confi

From: Cleber Rosa
Subject: Re: [PATCH v5 1/4] Jobs based on custom runners: documentation and configuration placeholder
Date: Wed, 24 Feb 2021 10:47:21 -0500

On Wed, Feb 24, 2021 at 12:57:52PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/23/21 7:09 PM, Cleber Rosa wrote:
> > Hi Phil,
> > 
> > I'm not following what you meant by "I cloned"... Are you experimenting
> > with this on a machine of your own and manually cloning the submodules?
> I meant "my test runner has been cloning ..."
> >> But reach the runner time limit of 2h.
> The first failure was 1h, I raised the job limit to the maximum
> I could use for this runner, 2h.
> >> The directory reports 3GB of source code.
> >>
> >> I don't think the series has been tested enough before posting,
> > 
> > Please take into consideration that this series, although simple in
> > content, touches and interacts with a lot of moving pieces, and
> > possibly with personal systems that I did not have, or will have,
> > access to.  As far as public testing proof goes, you can see a
> > pipeline here with this version of this series here:
> > 
> >    https://gitlab.com/cleber.gnu/qemu/-/pipelines/258982039/builds
> Expand the timeout and retry the same job on the same runner
> various times:
> diff --git a/.gitlab-ci.d/custom-runners.yml
> b/.gitlab-ci.d/custom-runners.yml
> @@ -17,6 +17,7 @@ variables:
>  # setup by the scripts/ci/setup/build-environment.yml task
>  # "Install basic packages to build QEMU on Ubuntu 18.04/20.04"
>  ubuntu-18.04-s390x-all-linux-static:
> + timeout: 2h 30m
>   allow_failure: true
>   needs: []
>   stage: build
> Each time it will clone more submodules.
> I stopped at the 3rd intent.
> > As I said elsewhere, I only noticed the recursive submodule being
> > applied to the existing jobs after I submitted the series.  Mea culpa.
> > But:
> > 
> >  * none of the jobs took noticeably longer than the previous baseline
> >  * there was one *container build failure* (safe to say it's not
> >    related)
> >  * all other jobs passed successfully
> I had less luck then (see the docker-dind jobs started on the custom
> runner commented elsewhere in this thread).

Hi Phil,

I replied to this issue elsewhere too... I assume you missed the
documentation and did not uncheck the "Run untagged jobs" as

> > And, along with the previous versions, this series were tested on all
> > the previously included architectures and operating systems.  It's
> > unfortunate that because of your experience at this time (my
> > apologies), you don't realize the amount of testing done so far.
> As I commented to Erik on IRC, the single difference I did
> is use the distribution runner, not the official one:
> $ sudo apt-get install gitlab-runner docker.io
> Then registered changing the path (/usr/bin/gitlab-runner instead
> of /usr/local/bin/gitlab-runner). Everything else left unchanged.

Assuming you did your experiments on Ubuntu 20.04:

   # dpkg -l gitlab-runner
  ||/ Name           Version              Architecture Description
  ii  gitlab-runner  11.2.0+dfsg-2ubuntu1 amd64        GitLab Runner - runs 
continuous integration (CI) jobs

This supposedly "single" difference, actually amounts to thousands of
changes (not counting the possible downstream patches, differences with
regards to packaging, etc):

  [gitlab-runner]$ git log --no-merges --oneline v11.2.0..v13.1.1 | wc -l

Version 13.1.1 referred above is what you'd get *if* using the

Like I said before, I very much appreciate your help reviewing this,
but unfortunately what you used was *WAY OFF* what was proposed.

And you're right, this version was not tested enough (on an
environment similar to what you used) before it was posted.

- Cleber.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]