Re: [PATCH v2 2/2] GitLab Gating CI: initial set of jobs, documentation and scripts

[Cleber Rosa <crosa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 8234 bytes --]

On Thu, Jul 09, 2020 at 11:30:29AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jul 08, 2020 at 10:46:57PM -0400, Cleber Rosa wrote:
> > This is a mapping of Peter's "remake-merge-builds" and
> > "pull-buildtest" scripts, gone through some updates, adding some build
> > option and removing others.
> > 
> > The jobs currently cover the machines that the QEMU project owns, and that
> > are setup and ready to run jobs:
> > 
> >  - Ubuntu 18.04 on S390x
> >  - Ubuntu 20.04 on aarch64
> > 
> > During the development of this set of jobs, the GitLab CI was tested
> > with many other architectures, including ppc64, s390x and aarch64,
> > along with the other OSs (not included here):
> > 
> >  - Fedora 30
> >  - FreeBSD 12.1
> > 
> > More information can be found in the documentation itself.
> > 
> > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > ---
> >  .gitlab-ci.d/gating.yml                | 146 +++++++++++++++++
> 
> AFAIK, the jobs in this file just augment what is already defined
> in the main .gitlab-ci.yml. Also since we're providing setup info
> for other people to configure custom runners, these jobs are usable
> for non-gating CI scenarios too.
>

If you mean that they introduced new jobs, you're right.

> IOW, the jobs in this file happen to be usable for gating, but they
> are not the only gating jobs, and can be used for non-gating reasons.
>

Right, I do not doubt these jobs may be useful to other people and on
scenarios other than "before merging a patch series".

> This is a complicated way of saying that gating.yml is not a desirable
> filename, so I'd suggest splitting it in two and having these files
> named based on what their contents is, rather than their use case:
> 
>    .gitlab-ci.d/runners-s390x.yml
>    .gitlab-ci.d/runners-aarch64.yml
> 
> The existing jobs in .gitlab-ci.yml could possibly be moved into
> a .gitlab-ci.d/runners-shared.yml file for consistency.
>

Do you imply that every gitlab CI job should be a gating job?  And
that the same jobs should be used when other people with their own
forks?  I find this problematic because:

* It would trigger pipelines with jobs that, unless every user has the
  same runners configured, would have unfulfilled jobs that don't have
  a matching hardware.

* It dilutes the idea that those jobs are inherently different with
  regards to the management of their infrastructure.

* It destroys the notion of layered testing, for whatever people find
  that worth it, where a faster turnaround could/would be possible
  with fewer jobs for every push, and many more jobs before a merge.

Finally, I find the split by runner architecture you suggested
problematic because different organizations may have jobs for the same
architecture.  I believe that files for different organizations may be
a better organization instead.  Entries in the MAINTAINERS are one
example where the grouping by architecture may not be optimal.

> >  .gitlab-ci.yml                         |   1 +
> >  docs/devel/testing.rst                 | 147 +++++++++++++++++
> >  scripts/ci/setup/build-environment.yml | 217 +++++++++++++++++++++++++
> >  scripts/ci/setup/gitlab-runner.yml     |  72 ++++++++
> >  scripts/ci/setup/inventory             |   2 +
> >  scripts/ci/setup/vars.yml              |  13 ++
> >  7 files changed, 598 insertions(+)
> >  create mode 100644 .gitlab-ci.d/gating.yml
> >  create mode 100644 scripts/ci/setup/build-environment.yml
> >  create mode 100644 scripts/ci/setup/gitlab-runner.yml
> >  create mode 100644 scripts/ci/setup/inventory
> >  create mode 100644 scripts/ci/setup/vars.yml
> > 
> > diff --git a/.gitlab-ci.d/gating.yml b/.gitlab-ci.d/gating.yml
> > new file mode 100644
> > index 0000000000..5562df5708
> > --- /dev/null
> > +++ b/.gitlab-ci.d/gating.yml
> > @@ -0,0 +1,146 @@
> > +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:
> > + tags:
> > + - ubuntu_18.04
> > + - s390x
> > + rules:
> > + - if: '$CI_COMMIT_REF_NAME == "staging"'
> 
> I think I'd make it more flexible in particular to allow multiple
> branches. For example I have multiple subsystems and have separate
> branches for each.
> 
> This could be as simple as allowing a regex prefix
> 
>   - if: '$CI_COMMIT_REF_NAME =~ /^staging/'
> 
> 
> 
> 
> > diff --git a/scripts/ci/setup/build-environment.yml b/scripts/ci/setup/build-environment.yml
> > new file mode 100644
> > index 0000000000..89b35386c7
> > --- /dev/null
> > +++ b/scripts/ci/setup/build-environment.yml
> > @@ -0,0 +1,217 @@
> > +---
> > +- name: Installation of basic packages to build QEMU
> > +  hosts: all
> > +  vars_files:
> > +    - vars.yml
> > +  tasks:
> > +    - name: Install basic packages to build QEMU on Ubuntu 18.04/20.04
> > +      apt:
> > +        update_cache: yes
> > +        # This matches the packages on tests/docker/Dockerfiles/ubuntu1804.docker
> 
> I'd be inclined to actually use docker on the custom runners.
> 
> eg. instead of having separate physical machines or VMs for each
> (distro, arch) pair, have a single host distro for the arch. Then
> use docker to provide the build environment against each distro.
> 
> IOW, a RHEL-8 aarch64 host, running docker for ubuntu18.04, fedora30
> etc.
>

I've come across so many caveats and corner cases that having the
lowest common denominator proved to be the smart and sane thing to do.
For instance, building on the example you gave, running a RHEL 8
aarch64 host is a NO GO Today because RHEL 8 doesn't ship with docker
and the gitlab runner needs to be taught to talk to, say, Podman.

gitlab-runner-helper images for different architectures, used to
prepare the docker images before running jobs, also proved to be a
challenge.

Finally, it's going to be very important for some organizations to
run tests outside of container environments.  For instance, Red Hat
needs to run QEMU+KVM tests on bare metal and on VMs, in addition
to containers.

> That way we don't end up duplicating all these packages, and instead
> can use  tests/docker/Dockerfiles/ubuntu1804.docker.  This ensures
> that if a user needs to reproduce a build failure on their own local
> aarch64 machine, they can run docker and get the exact same build
> architecture.
>

Like I explained before, containers-only won't cut it.  So, we need
tooling that is environment agnostic.  So far, ansible playbooks seem
to be a reasonable solution.  But duplicating information bothers me
as much as it seems to bother you, so we need to engage in common
tooling that is capable of generating those container environments,
but not be limited to it.  One example of a tool that seems to be
a good candidate is "Libvirt's" lcitool.

> It also has the benefit that we don't need to worry about how to
> setup gitlab runners for every distro we care about. We only need to
> do gitlab runner for the standard host distro, which spawns a pristine
> throwaway docker env.
> 
> I appreciate this is a big change from what you've done in this patch
> though, so don't consider this comment a blocker for initial merge.
> I think we should do this as the long term strategy though. Essentially
> for Linux builds, everything should always be container based.
>

Thanks for taking the time to give this feedback, and for making me
check again the premises that led to the proposal of this design.

Hopefully, this will be an improvement over the current state of
"pre-merge" testing, and at the same time can be the first step
towards a scenario that has more of the characteristics you pointed
out.

Best!
- Cleber.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]