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 <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. > > ... >
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.
signature.asc
Description: PGP signature
