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 <cr...@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. ... > + > +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/ > +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) ... > + > +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. Regards, Erik
