Re: [RFC PATCH 14/15] gitlab-ci: Allow forks to use different set of jobs

[Daniel P . Berrangé]

On Mon, Apr 19, 2021 at 04:57:55PM +0100, Alex Bennée wrote:
> 
> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> 
> > Forks run the same jobs than mainstream, which might be overkill.
> > Allow them to easily rebase their custom set, while keeping using
> > the mainstream templates, and ability to pick specific jobs from
> > the mainstream set.
> >
> > To switch to your set, simply add your .gitlab-ci.yml as
> > .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml (where CI_PROJECT_NAMESPACE
> > is your gitlab 'namespace', usually username). This file will be
> > used instead of the default mainstream set.
> >
> > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > ---
> >  .gitlab-ci.yml | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 718c8e004be..35fd35075db 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -9,7 +9,12 @@ generate-config:
> >      paths:
> >        - generated-config.yml
> >    script:
> > -    - cp .gitlab-ci.d/qemu-project.yml generated-config.yml
> > +    - if test -e .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml ;
> > +      then
> > +        cp .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml generated-config.yml ;
> > +      else
> > +        cp .gitlab-ci.d/qemu-project.yml generated-config.yml ;
> > +      fi
> 
> This is going to be a little clunky. I can see a use for the static
> forks that Danial proposes but I guess what is needed is a little
> expressiveness. So how to express things like:
> 
>  - I've only touched stuff in linux-user, so run only linux-user tests

This can be done with "rules" matching on files, but *only* if the
pipeline trigger is a merge request - specifically not a git branch
push, as the latter doesn't have the semantics you expect wrt
determining the "ancestor" to compare against. It only looks at commits
in the push, not those which may already have previously been pushed
on the branch.

>  - I'm working on KVM, run all KVM enabled builds and tests
> 
>  - I've changed the core TCG code, run everything that exercises that
> 
>  - I'm working on ARM, only build and run jobs that have ARM targets

If the stuff you work on is fairly static, we could potentially
allow env variables to be set by the user in their fork, which
the CI jobs use to filter jobs.

> I think we should define a minimum set of lightweight smoke tests that
> get the most bang for buck for catching sillies. I think checkpatch and
> dco checking should probably be in there - and maybe one of the bog
> standard build everything builds (maybe a random ../configure; make;
> make check on one of the supported LTS targets).

Could we have allow an env var  "QEMU_CI_SMOKE_TEST=1" which can be
set when pushing:

   git push  -o ci.variable="QEMU_CI_SMOKE_TEST=1"


which causes it to only do the minimum neccessary.

Alternatively, invert this, so do minimum smoke test by default
and require an env to run the full test. QEMU_CI_MAX=1

Potentially allow also  "QEMU_CI_EXTRA_JOBS=foo,bar,wizz"
to match against job jnames ?

> Then there is the question of defaults. Should we default to a minimised
> set unless asked or should the default be the full fat run everything?

With the direction gitlab is taking towards limiting CI minuts, it is
probably a safer bet to do a minimal smoke test by default and only
do the full test when definitely needed.

> We could I guess only switch to running everything for the staging
> branch and anything that is associated with a tag or a branch that has
> pull in the name?

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