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: 6192 bytes --]

On Thu, Jul 09, 2020 at 10:55:07AM +0200, Erik Skultety 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 +++++++++++++++++
> >  .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"'
> > + script:
> > + # --disable-libssh is needed because of https://bugs.launchpad.net/qemu/+bug/1838763
> > + # --disable-glusterfs is needed because there's no static version of those libs in distro supplied packages
> > + - ./configure --enable-debug --static --disable-system --disable-glusterfs --disable-libssh
> > + - make --output-sync -j`nproc`
> > + - make --output-sync -j`nproc` check V=1
> > + - make --output-sync -j`nproc` check-tcg V=1
> 
> I know this patch doesn't introduce a FreeBSD job, but later in the patch it's
> clear you'd want to introduce them at some point, so:
> 'nproc' doesn't exist on FreeBSD, but `getconf _NPROCESSORS_ONLN` does, so you
> may want to use it right from the start.
> 
> ...
>

Sure, thanks for the info.

> > +
> > +CI
> > +==
> > +
> > +QEMU has configurations enabled for a number of different CI services.
> > +The most update information about them and their status can be found
> 
> s/update/up to date/
>

Good catch!

> > +at::
> > +
> > +   https://wiki.qemu.org/Testing/CI
> > +
> > +Gating CI
> > +----------
> > +
> > +A Pull Requests will only to be merged if they successfully go through
> 
> s/A /
> s/to be/be/
> 
> > +a different set of CI jobs.  GitLab's CI is the service/framework used
> 
> s/a different set/different sets/       (I may be wrong with this one)
> 
> ...

I think you're right.  But, to keep it simpler, I'm using:

"Pull Requests will only be merged if they successfully go through
different CI jobs."

> 
> > +
> > +gitlab-runner setup and registration
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +The gitlab-runner agent needs to be installed on each machine that
> > +will run jobs.  The association between a machine and a GitLab project
> > +happens with a registration token.  To find the registration token for
> > +your repository/project, navigate on GitLab's web UI to:
> > +
> > + * Settings (the gears like icon), then
> > + * CI/CD, then
> > + * Runners, and click on the "Expand" button, then
> > + * Under "Set up a specific Runner manually", look for the value under
> > +   "Use the following registration token during setup"
> > +
> > +Edit the ``scripts/ci/setup/vars.yml`` file, setting the
> > +``gitlab_runner_registration_token`` variable to the value obtained
> > +earlier.
> > +
> > +.. note:: gitlab-runner is not available from the standard location
> > +          for all OS and architectures combinations.  For some systems,
> > +          a custom build may be necessary.  Some builds are avaiable
> > +          at https://cleber.fedorapeople.org/gitlab-runner/ and this
> > +          URI may be used as a value on ``vars.yml``
> > +
> > +To run the playbook, execute::
> > +
> > +  cd scripts/ci/setup
> > +  ansible-playbook -i inventory gitlab-runner.yml
> > +
> > +.. note:: there are currently limitations to gitlab-runner itself when
> > +          setting up a service under FreeBSD systems.  You will need to
> > +          perform steps 4 to 10 manually, as described at
> > +          https://docs.gitlab.com/runner/install/freebsd.html
> 
> What kinds of limitations? Is it architecture constrained maybe? I'm asking
> because we have all of the steps covered by an Ansible playbook, so I kinda got
> triggered by the word "manually". Also, the document only mentions 9 steps
> overall.
>

FreeBSD's "service management" (systemd/sys-v like) is not covered by
the GO library[1] used on gitlab-runner.  It's not ideal, and the
second best solution would be to script the equivalent handling within
the playbook, but I remember trying and finding some inconsistencies.
Then, I had to give it up and defer to whenever a FreeBSD job is
actually added.

> Regards,
> Erik

[1] - https://github.com/ayufan/golang-kardianos-service

Thanks for the review, I'll be sending a v3 shortly.
- Cleber.

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