mbox series

[v4,0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI)

Message ID 20201019015003.1527746-1-crosa@redhat.com
Headers show
Series GitLab Custom Runners and Jobs (was: QEMU Gating CI) | expand

Message

Cleber Rosa Oct. 19, 2020, 1:49 a.m. UTC
TL;DR: this should allow the QEMU maintainer to push to the staging
branch, and have custom jobs running on the project's aarch64 and
s390x machines.  Simple usage looks like:

   git push remote staging
   ./scripts/ci/gitlab-pipeline-status --verbose --wait

Long version:

The idea about a public facing Gating CI for QEMU was summarized in an
RFC[1].  Since then, it was decided that a simpler version should be
attempted first.

At this point, there are two specific runners (an aarch64 and an s390)
registered with GitLab, at https://gitlab.com/qemu-project, currently
setup to the "qemu" repository.

Changes from v3:

- Applied changes to match <20201014135416.1290679-1-pbonzini@redhat.com>,
  that is, added ninja-build to "build-environment.yml" list of packages
  and enabled PowerTools repository on CentOS 8.

Changes from v2:

- The overall idea of "Gating CI" has been re-worded "custom runners",
  given that the other jobs running on shared runners are also
  considered gating (Daniel)

- Fixed wording and typos on the documentation, including:
 * update -> up to date (Erik)
 * a different set of CI jobs -> different CI jobs (Erik)
 * Pull requests will only be merged -> code will only be merged (Stefan)
 * Setup -> set up (Stefan)
 * them -> they (Stefan)
 * the -> where the (Stefan)
 * dropped "in the near future" (Stefan)

- Changed comment on "build-environment.yml" regarding the origin of
  the package list (Stefan)

- Removed inclusion of "vars.yml" from "build-environment.yml", given that
  no external variable is used there

- Updated package list in "build-environment.yml" from current
  dockerfiles

- Tested "build-environment" on Fedora 31 and 32 (in addition to Fedora 30),
  and noted that it's possible to use it on those distros

- Moved CI documentation from "testing.rst" to its own file (Phillipe)

- Split "GitLab Gating CI: initial set of jobs, documentation and scripts"
  into (Phillipe):
  1) Basic documentation and configuration (gitlab-ci.yml) placeholder
  2) Playbooks for setting up a build environment
  3) Playbooks for setting up gitlab-runner
  4) Actual GitLab CI jobs configuration

- Set custom jobs to be on the "build" stage, given that they combine
  build and test.

- Set custom jobs to not depend on any other job, so they can start
  right away.

- Set rules for starting jobs so that all pushing to any branch that
  start with name "staging".  This allows the project maintainer to
  use the "push to staging" workflow, while also allowing others to
  generate similar jobs.  If this project has configured custom
  runners, the jobs will run, if not, the pipeline will be marked as
  "stuck".

- Changed "scripts" on custom jobs to follow the now common pattern
  (on other jobs) of creating a "build" directory.

Changes from v1:

- Added jobs that require specific GitLab runners already available
  (Ubuntu 20.04 on aarch64, and Ubuntu 18.04 on s390x)
- Removed jobs that require specific GitLab runners not yet available
  (Fedora 30, FreeBSD 12.1)
- Updated documentation
- Added copyright and license to new scripts
- Moved script to from "contrib" to "scripts/ci/"
- Moved setup playbooks form "contrib" to "scripts/ci/setup"
- Moved "gating.yml" to ".gitlab-ci.d" directory
- Removed "staging" only branch restriction on jobs defined in
  ".gitlab-ci.yml", assumes that the additional jobs on the staging
  branch running on the freely available gitlab shared runner are
  positive
- Dropped patches 1-3 (already merged)
- Simplified amount of version specifity on Ubuntu, from 18.04.3 to
  simply 18.04 (assumes no diverse minor levels will be used or
  specific runners)

Changes from the RFC patches[2] accompanying the RFC document:

- Moved gating job definitions to .gitlab-ci-gating.yml
- Added info on "--disable-libssh" build option requirement
  (https://bugs.launchpad.net/qemu/+bug/1838763) to Ubuntu 18.04 jobs
- Added info on "--disable-glusterfs" build option requirement
  (there's no static version of those libs in distro supplied
  packages) to one
- Dropped ubuntu-18.04.3-x86_64-notools job definition, because it
  doesn't fall into the general scope of gating job described by PMM
  (and it did not run any test)
- Added w32 and w64 cross builds based on Fedora 30
- Added a FreeBSD based job that builds all targets and runs `make
  check`
- Added "-j`nproc`" and "-j`sysctl -n hw.ncpu`" options to make as a
  simple but effective way of speeding up the builds and tests by
  using a number of make jobs matching the number of CPUs
- Because the Ansible playbooks reference the content on Dockerfiles,
  some fixes to some Dockerfiles caught in the process were included
- New patch with script to check or wait on a pipeline execution

[1] - https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg00231.html
[2] - https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg00154.html

Cleber Rosa (4):
  Jobs based on custom runners: documentation and configuration
    placeholder
  Jobs based on custom runners: build environment docs and playbook
  Jobs based on custom runners: docs and gitlab-runner setup playbook
  Jobs based on custom runners: add job definitions for QEMU's machines

 .gitlab-ci.d/custom-runners.yml        | 206 ++++++++++++++++++++++
 .gitlab-ci.yml                         |   1 +
 docs/devel/ci.rst                      | 149 ++++++++++++++++
 docs/devel/index.rst                   |   1 +
 scripts/ci/setup/.gitignore            |   1 +
 scripts/ci/setup/build-environment.yml | 233 +++++++++++++++++++++++++
 scripts/ci/setup/gitlab-runner.yml     |  72 ++++++++
 scripts/ci/setup/inventory             |   2 +
 scripts/ci/setup/vars.yml.template     |  13 ++
 9 files changed, 678 insertions(+)
 create mode 100644 .gitlab-ci.d/custom-runners.yml
 create mode 100644 docs/devel/ci.rst
 create mode 100644 scripts/ci/setup/.gitignore
 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.template

Comments

Thomas Huth Jan. 28, 2021, 11:51 a.m. UTC | #1
On 19/10/2020 03.49, Cleber Rosa wrote:
> TL;DR: this should allow the QEMU maintainer to push to the staging
> branch, and have custom jobs running on the project's aarch64 and
> s390x machines.  Simple usage looks like:
> 
>     git push remote staging
>     ./scripts/ci/gitlab-pipeline-status --verbose --wait

  Hi Cleber,

since the QEMU project is now using the gitlab repo as main repository, it 
should now be possible to finally enable these custom runners, too, I think.

Could you elaborate on what's left to do to get the s390x and aarch64 
runners enabled, and rebase your patches if necessary?

  Thanks,
   Thomas
Cleber Rosa Feb. 3, 2021, 9:06 p.m. UTC | #2
On Thu, Jan 28, 2021 at 12:51:20PM +0100, Thomas Huth wrote:
> On 19/10/2020 03.49, Cleber Rosa wrote:
> > TL;DR: this should allow the QEMU maintainer to push to the staging
> > branch, and have custom jobs running on the project's aarch64 and
> > s390x machines.  Simple usage looks like:
> > 
> >     git push remote staging
> >     ./scripts/ci/gitlab-pipeline-status --verbose --wait
> 
>  Hi Cleber,
> 
> since the QEMU project is now using the gitlab repo as main repository, it
> should now be possible to finally enable these custom runners, too, I think.
>

I couldn't agree more!

> Could you elaborate on what's left to do to get the s390x and aarch64
> runners enabled, and rebase your patches if necessary?
>

Basically what's needed is to enable the jobs, meaning committing the
relevant snippets to the "gitlab-ci.{yml,d/*}" files.

Both ansible playbooks have been run on both machines, so the gitlab-runner
and tooling to build QEMU are in place.  The gitlab-runners have also
been registered on the "qemu-project/qemu" GitLab repo.

I'll send a rebased/updated version of the playbooks, gitlab-ci.yml
configurations, etc.  In it, I'll propose that we enable the jobs, but
ignore errors for now (allow_failure: true), because it'll ease the
review.  Once the jobs prove mature, waiving of failures can be
removed.

How does that sound?

Thanks,
- Cleber.

>  Thanks,
>   Thomas
Thomas Huth Feb. 4, 2021, 11:27 a.m. UTC | #3
On 03/02/2021 22.06, Cleber Rosa wrote:
> On Thu, Jan 28, 2021 at 12:51:20PM +0100, Thomas Huth wrote:
[...]
>> Could you elaborate on what's left to do to get the s390x and aarch64
>> runners enabled, and rebase your patches if necessary
> 
> Basically what's needed is to enable the jobs, meaning committing the
> relevant snippets to the "gitlab-ci.{yml,d/*}" files.
> 
> Both ansible playbooks have been run on both machines, so the gitlab-runner
> and tooling to build QEMU are in place.  The gitlab-runners have also
> been registered on the "qemu-project/qemu" GitLab repo.
> 
> I'll send a rebased/updated version of the playbooks, gitlab-ci.yml
> configurations, etc.  In it, I'll propose that we enable the jobs, but
> ignore errors for now (allow_failure: true), because it'll ease the
> review.  Once the jobs prove mature, waiving of failures can be
> removed.
> 
> How does that sound?

Sounds good, please go ahead!

  Thanks,
   Thomas