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

[Cleber Rosa]

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
instructed.

> > 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
  1477

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

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.

Regards,
- Cleber.

signature.asc
Description: PGP signature