Re: [PATCH v3 4/4] Jobs based on custom runners: add job definitions for QEMU's machines

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Oct 14, 2020 at 05:13:56PM -0400, Cleber Rosa wrote:
> On Wed, Oct 14, 2020 at 06:46:55PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Oct 14, 2020 at 01:21:40AM -0400, Cleber Rosa wrote:
> > > The QEMU project has two machines (aarch64 and s390) that can be used
> > > for jobs that do build and run tests.  This introduces those jobs,
> > > which are a mapping of custom scripts used for the same purpose.
> > > 
> > > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > > ---
> > >  .gitlab-ci.d/custom-runners.yml | 192 ++++++++++++++++++++++++++++++++
> > >  1 file changed, 192 insertions(+)
> > > 
> > > diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
> > > index 3004da2bda..5b51d1b336 100644
> > > --- a/.gitlab-ci.d/custom-runners.yml
> > > +++ b/.gitlab-ci.d/custom-runners.yml
> > > @@ -12,3 +12,195 @@
> > >  # strategy.
> > >  variables:
> > >    GIT_SUBMODULE_STRATEGY: recursive
> > > +
> > > +# All ubuntu-18.04 jobs should run successfully in an environment
> > > +# 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:
> > > + needs: []
> > > + stage: build
> > > + tags:
> > > + - ubuntu_18.04
> > > + - s390x
> > > + rules:
> > > + - if: '$CI_COMMIT_BRANCH =~ /^staging/'
> > 
> > IIRC, in the previous v2 (or was it v1) we discussed changing this
> > so that users who provide their own runners, don't have to always
> > use the "staging" branch name.
> >
> 
> Right, and what I got from that is that users can use a *prefix* as a
> flag to indicate that they want the extra set of jobs.
> 
> > IIUC, the key thing is that we don't want the job running on the
> > "master" or "stable-*" branches in the primary QEMU git. So could
> > check
> > 
> >    $CI_PROJECT_NAMESPACE == 'qemu-project'
> >    &&
> >    $CI_COMMIT_BRANCH !~ '^master$'
> >    &&
> >    $CI_COMMIT_BRANCH !~ '^stable-$'
> > 
> > which would let it work on users forks no matter what branch names
> > they use
> > 
> > What happens to the job if the user doesn't have runners ? Is it
> > simply skipped, or does the pipeline stall and get marked as failed ?
> >
> 
> The pipeline gets "stuck" (literaly, that's the status name it gets).
> That's the main issue that made me believe that opting *in* (by using
> a common branch name prefix) was the simpler solution.

Hmm, that's very annoying behaviour.

> > If the jobs aren't auto-skiped, we would need to add an env variable
> > 
> >    (
> >    $CI_PROJECT_NAMESPACE == 'qemu-project'
> >    &&
> >    $CI_COMMIT_BRANCH !~ '^master$'
> >    &&
> >    $CI_COMMIT_BRANCH !~ '^stable-$'
> >    )
> >    ||
> >    $QEMU_ENABLE_CUSTOM_RUNNERS == 'yes'
> > 
> > and require the user to set the QEMU_ENABLE_CUSTOM_RUNNERS variable
> > in the web UI for their fork
> >
> 
> We can do that, but I think it's more than we need.  The odds that a
> user will have all of the same runners, and will be able to run all
> the extra jobs, are very very low IMO.  Right from the start, very few
> people have an s390 machine running Ubuntu 18.04.
> 
> So, I believe that whenever a user pushes to a branch such as
> "staging-topic-foo", he will have to deal with some of the extra jobs
> (such as canceling the ones that will never run) anyway.  Having to
> deal with those on every single push, or alternatively having to turn
> on/off $QEMU_ENABLE_CUSTOM_RUNNERS doesn't the best experience to me.
> 
> The "staging" prefix convention (with a better prefix name now or in
> the future?) seems to result in the best experience to me.

Well "staging" prefix wasn';t appealing to me since none of the branches
I work on have such a name prefix.

> > That all said, I don't mind if you postpone this rules change to a
> > followup patch.
> >
> 
> OK, let me know if you agree with my explanation above, or if you
> really want to see a followup patch.

Just ignore it for now. I'll do more thinking to see if I can figure
out a more attractive solution.



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|