[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 4/4] Jobs based on custom runners: add job definitions for
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v3 4/4] Jobs based on custom runners: add job definitions for QEMU's machines |
Date: |
Thu, 15 Oct 2020 09:34:31 +0100 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
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 :|
- Re: [PATCH v3 2/4] Jobs based on custom runners: build environment docs and playbook, (continued)
[PATCH v3 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook, Cleber Rosa, 2020/10/14
[PATCH v3 4/4] Jobs based on custom runners: add job definitions for QEMU's machines, Cleber Rosa, 2020/10/14