| Message ID | 20201014052140.1146924-1-crosa@redhat.com |
|---|---|
| Headers | show |
| Series | GitLab Custom Runners and Jobs (was: QEMU Gating CI) | expand |
On Wed, Oct 14, 2020 at 01:21:40AM -0400, Cleber Rosa wrote: > The QEMU project has two machines (aarch64 and s390) that can be used > for jobs that do build and run tests. This introduces those jobs, > which are a mapping of custom scripts used for the same purpose. > > Signed-off-by: Cleber Rosa <crosa@redhat.com> > --- > .gitlab-ci.d/custom-runners.yml | 192 ++++++++++++++++++++++++++++++++ > 1 file changed, 192 insertions(+) > > diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml > index 3004da2bda..5b51d1b336 100644 > --- a/.gitlab-ci.d/custom-runners.yml > +++ b/.gitlab-ci.d/custom-runners.yml > @@ -12,3 +12,195 @@ > # strategy. > 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: > + needs: [] > + stage: build > + tags: > + - ubuntu_18.04 > + - s390x > + rules: > + - if: '$CI_COMMIT_BRANCH =~ /^staging/' IIRC, in the previous v2 (or was it v1) we discussed changing this so that users who provide their own runners, don't have to always use the "staging" branch name. IIUC, the key thing is that we don't want the job running on the "master" or "stable-*" branches in the primary QEMU git. So could check $CI_PROJECT_NAMESPACE == 'qemu-project' && $CI_COMMIT_BRANCH !~ '^master$' && $CI_COMMIT_BRANCH !~ '^stable-$' which would let it work on users forks no matter what branch names they use What happens to the job if the user doesn't have runners ? Is it simply skipped, or does the pipeline stall and get marked as failed ? If the jobs aren't auto-skiped, we would need to add an env variable ( $CI_PROJECT_NAMESPACE == 'qemu-project' && $CI_COMMIT_BRANCH !~ '^master$' && $CI_COMMIT_BRANCH !~ '^stable-$' ) || $QEMU_ENABLE_CUSTOM_RUNNERS == 'yes' and require the user to set the QEMU_ENABLE_CUSTOM_RUNNERS variable in the web UI for their fork That all said, I don't mind if you postpone this rules change to a followup patch. > + script: > + # --disable-libssh is needed because of https://bugs.launchpad.net/qemu/+bug/1838763 This bug links to https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 which is marked as fixed. So I'm thinking we can drop the --disable-libssh arg from all these jobs > + # --disable-glusterfs is needed because there's no static version of those libs in distro supplied packages > + - mkdir build > + - cd build > + - ../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 Regards, Daniel
On Wed, Oct 14, 2020 at 06:30:09PM +0100, Daniel P. Berrangé wrote: > On Wed, Oct 14, 2020 at 01:21:38AM -0400, Cleber Rosa wrote: > > To run basic jobs on custom runners, the environment needs to be > > properly set up. The most common requirement is having the right > > packages installed. > > > > The playbook introduced here covers a number of different Linux > > distributions and FreeBSD, and are intended to provide a reproducible > > environment. > > > > Signed-off-by: Cleber Rosa <crosa@redhat.com> > > --- > > docs/devel/ci.rst | 32 ++++ > > scripts/ci/setup/build-environment.yml | 220 +++++++++++++++++++++++++ > > scripts/ci/setup/inventory | 2 + > > 3 files changed, 254 insertions(+) > > create mode 100644 scripts/ci/setup/build-environment.yml > > create mode 100644 scripts/ci/setup/inventory > > > > diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst > > index 41a4bbddad..208b5e399b 100644 > > --- a/docs/devel/ci.rst > > +++ b/docs/devel/ci.rst > > @@ -52,3 +52,35 @@ As a general rule, those newly added contributed jobs should run as > > The precise minimum requirements and exact rules for machine > > configuration documentation/scripts, and the success rate of jobs are > > still to be defined. > > + > > +Machine Setup Howto > > +------------------- > > + > > +For all Linux based systems, the setup can be mostly automated by the > > +execution of two Ansible playbooks. Start by adding your machines to > > +the ``inventory`` file under ``scripts/ci/setup``, such as this:: > > + > > + [local] > > + fully.qualified.domain > > + other.machine.hostname > > + > > +You may need to set some variables in the inventory file itself. One > > +very common need is to tell Ansible to use a Python 3 interpreter on > > +those hosts. This would look like:: > > + > > + [local] > > + fully.qualified.domain ansible_python_interpreter=/usr/bin/python3 > > + other.machine.hostname ansible_python_interpreter=/usr/bin/python3 > > + > > +Build environment > > +~~~~~~~~~~~~~~~~~ > > + > > +The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will > > +set up machines with the environment needed to perform builds and run > > +QEMU tests. It covers a number of different Linux distributions and > > +FreeBSD. > > + > > +To run the playbook, execute:: > > + > > + cd scripts/ci/setup > > + ansible-playbook -i inventory build-environment.yml > > diff --git a/scripts/ci/setup/build-environment.yml b/scripts/ci/setup/build-environment.yml > > new file mode 100644 > > index 0000000000..0e8894bca9 > > --- /dev/null > > +++ b/scripts/ci/setup/build-environment.yml > > @@ -0,0 +1,220 @@ > > +--- > > +- name: Installation of basic packages to build QEMU > > + hosts: all > > + tasks: > > + - name: Install basic packages to build QEMU on Ubuntu 18.04/20.04 > > + apt: > > + update_cache: yes > > + # Originally from tests/docker/dockerfiles/ubuntu1804.docker > > + pkg: > > + - ccache > > + - clang > > + - gcc > > + - gettext > > + - git > > + - glusterfs-common > > + - libaio-dev > > + - libattr1-dev > > + - libbrlapi-dev > > + - libbz2-dev > > + - libcacard-dev > > + - libcap-ng-dev > > + - libcurl4-gnutls-dev > > + - libdrm-dev > > + - libepoxy-dev > > + - libfdt-dev > > + - libgbm-dev > > + - libgtk-3-dev > > + - libibverbs-dev > > + - libiscsi-dev > > + - libjemalloc-dev > > + - libjpeg-turbo8-dev > > + - liblzo2-dev > > + - libncurses5-dev > > + - libncursesw5-dev > > + - libnfs-dev > > + - libnss3-dev > > + - libnuma-dev > > + - libpixman-1-dev > > + - librados-dev > > + - librbd-dev > > + - librdmacm-dev > > + - libsasl2-dev > > + - libsdl2-dev > > + - libseccomp-dev > > + - libsnappy-dev > > + - libspice-protocol-dev > > + - libssh-dev > > + - libusb-1.0-0-dev > > + - libusbredirhost-dev > > + - libvdeplug-dev > > + - libvte-2.91-dev > > + - libzstd-dev > > + - make > > + - python3-yaml > > + - python3-sphinx > > + - sparse > > + - xfslibs-dev > > This needs updating to add meson, and with Paolo's series today you > might as well go ahead and add ninja-build immediately too > > https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg04025.html > > Same for all the other distro package lists. > > Good point, will do. Thanks! - 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 :| > >
On Wed, Oct 14, 2020 at 02:59:58PM -0400, Cleber Rosa wrote: > On Wed, Oct 14, 2020 at 06:30:09PM +0100, Daniel P. Berrangé wrote: > > > > This needs updating to add meson, and with Paolo's series today you > > might as well go ahead and add ninja-build immediately too > > I replied too quickly, but allow me to get this right: meson is *not* included in the dockerfiles (and other similar configurations), and all setups I found rely on the submodule. Are suggesting to add meson and diverge from the dockerfiles? > > https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg04025.html > > ^ I'll add meson according to this, of course. Thanks, - Cleber. > > Same for all the other distro package lists. > > > >
On Wed, Oct 14, 2020 at 06:46:55PM +0100, Daniel P. Berrangé wrote: > On Wed, Oct 14, 2020 at 01:21:40AM -0400, Cleber Rosa wrote: > > The QEMU project has two machines (aarch64 and s390) that can be used > > for jobs that do build and run tests. This introduces those jobs, > > which are a mapping of custom scripts used for the same purpose. > > > > Signed-off-by: Cleber Rosa <crosa@redhat.com> > > --- > > .gitlab-ci.d/custom-runners.yml | 192 ++++++++++++++++++++++++++++++++ > > 1 file changed, 192 insertions(+) > > > > diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml > > index 3004da2bda..5b51d1b336 100644 > > --- a/.gitlab-ci.d/custom-runners.yml > > +++ b/.gitlab-ci.d/custom-runners.yml > > @@ -12,3 +12,195 @@ > > # strategy. > > 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: > > + needs: [] > > + stage: build > > + tags: > > + - ubuntu_18.04 > > + - s390x > > + rules: > > + - if: '$CI_COMMIT_BRANCH =~ /^staging/' > > IIRC, in the previous v2 (or was it v1) we discussed changing this > so that users who provide their own runners, don't have to always > use the "staging" branch name. > Right, and what I got from that is that users can use a *prefix* as a flag to indicate that they want the extra set of jobs. > IIUC, the key thing is that we don't want the job running on the > "master" or "stable-*" branches in the primary QEMU git. So could > check > > $CI_PROJECT_NAMESPACE == 'qemu-project' > && > $CI_COMMIT_BRANCH !~ '^master$' > && > $CI_COMMIT_BRANCH !~ '^stable-$' > > which would let it work on users forks no matter what branch names > they use > > What happens to the job if the user doesn't have runners ? Is it > simply skipped, or does the pipeline stall and get marked as failed ? > The pipeline gets "stuck" (literaly, that's the status name it gets). That's the main issue that made me believe that opting *in* (by using a common branch name prefix) was the simpler solution. > If the jobs aren't auto-skiped, we would need to add an env variable > > ( > $CI_PROJECT_NAMESPACE == 'qemu-project' > && > $CI_COMMIT_BRANCH !~ '^master$' > && > $CI_COMMIT_BRANCH !~ '^stable-$' > ) > || > $QEMU_ENABLE_CUSTOM_RUNNERS == 'yes' > > and require the user to set the QEMU_ENABLE_CUSTOM_RUNNERS variable > in the web UI for their fork > We can do that, but I think it's more than we need. The odds that a user will have all of the same runners, and will be able to run all the extra jobs, are very very low IMO. Right from the start, very few people have an s390 machine running Ubuntu 18.04. So, I believe that whenever a user pushes to a branch such as "staging-topic-foo", he will have to deal with some of the extra jobs (such as canceling the ones that will never run) anyway. Having to deal with those on every single push, or alternatively having to turn on/off $QEMU_ENABLE_CUSTOM_RUNNERS doesn't the best experience to me. The "staging" prefix convention (with a better prefix name now or in the future?) seems to result in the best experience to me. > That all said, I don't mind if you postpone this rules change to a > followup patch. > OK, let me know if you agree with my explanation above, or if you really want to see a followup patch. > > + script: > > + # --disable-libssh is needed because of https://bugs.launchpad.net/qemu/+bug/1838763 > > This bug links to > > https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 > > which is marked as fixed. So I'm thinking we can drop the --disable-libssh > arg from all these jobs > OK, I'll double check that and, if the fix is comfirmed beyond the bug tracker, I'll update it. Thanks! - Cleber. > > + # --disable-glusterfs is needed because there's no static version of those libs in distro supplied packages > > + - mkdir build > > + - cd build > > + - ../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 > > > > 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 :|
On Wed, Oct 14, 2020 at 05:14:01PM -0400, Cleber Rosa wrote: > On Wed, Oct 14, 2020 at 06:46:55PM +0100, Daniel P. Berrangé wrote: > > > > This bug links to > > > > https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 > > > > which is marked as fixed. So I'm thinking we can drop the --disable-libssh > > arg from all these jobs > > > > OK, I'll double check that and, if the fix is comfirmed beyond the bug > tracker, I'll update it. > I was still able to reproduce the build failure with the latest packages. The last update on the bug, is very misleading, but there's a hint of its outcome: --- Martin Wimpress (flexiondotorg) on 2019-12-17 tags: added: rls-bb-notfixing tags: removed: bionic no longer affects: libssh (Ubuntu Bionic) --- So, *notfixing* means it no longer affects that package on that distro? Right... Anyway, keeping this AS IS. Regards, - Cleber.
On 15/10/2020 01.24, Cleber Rosa wrote: > On Wed, Oct 14, 2020 at 05:14:01PM -0400, Cleber Rosa wrote: >> On Wed, Oct 14, 2020 at 06:46:55PM +0100, Daniel P. Berrangé wrote: >>> >>> This bug links to >>> >>> https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 >>> >>> which is marked as fixed. So I'm thinking we can drop the --disable-libssh >>> arg from all these jobs >>> >> >> OK, I'll double check that and, if the fix is comfirmed beyond the bug >> tracker, I'll update it. >> > > I was still able to reproduce the build failure with the latest packages. > > The last update on the bug, is very misleading, but there's a hint of > its outcome: > > --- > Martin Wimpress (flexiondotorg) on 2019-12-17 > tags: added: rls-bb-notfixing > tags: removed: bionic > no longer affects: libssh (Ubuntu Bionic) > --- > > So, *notfixing* means it no longer affects that package on that > distro? Right... > > Anyway, keeping this AS IS. I can confirm that the libssh bug is still there in Ubuntu 18.04 ... when I was updating our .travis.yml some weeks ago to stop using Xenial, I also hit the bug again on Bionic. Maybe rather a question for Peter, but what about updating the runners to 20.04 (Focal) instead? The libssh bug is gone there. Thomas
On Wed, Oct 14, 2020 at 03:19:47PM -0400, Cleber Rosa wrote: > On Wed, Oct 14, 2020 at 02:59:58PM -0400, Cleber Rosa wrote: > > On Wed, Oct 14, 2020 at 06:30:09PM +0100, Daniel P. Berrangé wrote: > > > > > > This needs updating to add meson, and with Paolo's series today you > > > might as well go ahead and add ninja-build immediately too > > > > > I replied too quickly, but allow me to get this right: meson is *not* > included in the dockerfiles (and other similar configurations), and > all setups I found rely on the submodule. Are suggesting to add meson > and diverge from the dockerfiles? Doh, right, I forgot that we use the submodule for now, since we need such a new meson. So ignore this... > > > https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg04025.html > > > > > ^ I'll add meson according to this, of course. Just ninja is needed 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 :|
On Wed, Oct 14, 2020 at 07:24:30PM -0400, Cleber Rosa wrote: > On Wed, Oct 14, 2020 at 05:14:01PM -0400, Cleber Rosa wrote: > > On Wed, Oct 14, 2020 at 06:46:55PM +0100, Daniel P. Berrangé wrote: > > > > > > This bug links to > > > > > > https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 > > > > > > which is marked as fixed. So I'm thinking we can drop the --disable-libssh > > > arg from all these jobs > > > > > > > OK, I'll double check that and, if the fix is comfirmed beyond the bug > > tracker, I'll update it. > > > > I was still able to reproduce the build failure with the latest packages. > > The last update on the bug, is very misleading, but there's a hint of > its outcome: > > --- > Martin Wimpress (flexiondotorg) on 2019-12-17 > tags: added: rls-bb-notfixing > tags: removed: bionic > no longer affects: libssh (Ubuntu Bionic) > --- > > So, *notfixing* means it no longer affects that package on that > distro? Right... Urgh, launchpad is such a confusing bug tracker :-( > Anyway, keeping this AS IS. Yep Regards, Daniel
On Wed, Oct 14, 2020 at 05:13:56PM -0400, Cleber Rosa wrote: > On Wed, Oct 14, 2020 at 06:46:55PM +0100, Daniel P. Berrangé wrote: > > On Wed, Oct 14, 2020 at 01:21:40AM -0400, Cleber Rosa wrote: > > > The QEMU project has two machines (aarch64 and s390) that can be used > > > for jobs that do build and run tests. This introduces those jobs, > > > which are a mapping of custom scripts used for the same purpose. > > > > > > Signed-off-by: Cleber Rosa <crosa@redhat.com> > > > --- > > > .gitlab-ci.d/custom-runners.yml | 192 ++++++++++++++++++++++++++++++++ > > > 1 file changed, 192 insertions(+) > > > > > > diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml > > > index 3004da2bda..5b51d1b336 100644 > > > --- a/.gitlab-ci.d/custom-runners.yml > > > +++ b/.gitlab-ci.d/custom-runners.yml > > > @@ -12,3 +12,195 @@ > > > # strategy. > > > 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: > > > + needs: [] > > > + stage: build > > > + tags: > > > + - ubuntu_18.04 > > > + - s390x > > > + rules: > > > + - if: '$CI_COMMIT_BRANCH =~ /^staging/' > > > > IIRC, in the previous v2 (or was it v1) we discussed changing this > > so that users who provide their own runners, don't have to always > > use the "staging" branch name. > > > > Right, and what I got from that is that users can use a *prefix* as a > flag to indicate that they want the extra set of jobs. > > > IIUC, the key thing is that we don't want the job running on the > > "master" or "stable-*" branches in the primary QEMU git. So could > > check > > > > $CI_PROJECT_NAMESPACE == 'qemu-project' > > && > > $CI_COMMIT_BRANCH !~ '^master$' > > && > > $CI_COMMIT_BRANCH !~ '^stable-$' > > > > which would let it work on users forks no matter what branch names > > they use > > > > What happens to the job if the user doesn't have runners ? Is it > > simply skipped, or does the pipeline stall and get marked as failed ? > > > > The pipeline gets "stuck" (literaly, that's the status name it gets). > That's the main issue that made me believe that opting *in* (by using > a common branch name prefix) was the simpler solution. Hmm, that's very annoying behaviour. > > If the jobs aren't auto-skiped, we would need to add an env variable > > > > ( > > $CI_PROJECT_NAMESPACE == 'qemu-project' > > && > > $CI_COMMIT_BRANCH !~ '^master$' > > && > > $CI_COMMIT_BRANCH !~ '^stable-$' > > ) > > || > > $QEMU_ENABLE_CUSTOM_RUNNERS == 'yes' > > > > and require the user to set the QEMU_ENABLE_CUSTOM_RUNNERS variable > > in the web UI for their fork > > > > We can do that, but I think it's more than we need. The odds that a > user will have all of the same runners, and will be able to run all > the extra jobs, are very very low IMO. Right from the start, very few > people have an s390 machine running Ubuntu 18.04. > > So, I believe that whenever a user pushes to a branch such as > "staging-topic-foo", he will have to deal with some of the extra jobs > (such as canceling the ones that will never run) anyway. Having to > deal with those on every single push, or alternatively having to turn > on/off $QEMU_ENABLE_CUSTOM_RUNNERS doesn't the best experience to me. > > The "staging" prefix convention (with a better prefix name now or in > the future?) seems to result in the best experience to me. Well "staging" prefix wasn';t appealing to me since none of the branches I work on have such a name prefix. > > That all said, I don't mind if you postpone this rules change to a > > followup patch. > > > > OK, let me know if you agree with my explanation above, or if you > really want to see a followup patch. Just ignore it for now. I'll do more thinking to see if I can figure out a more attractive solution. 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 :|
On Thu, Oct 15, 2020 at 09:29:40AM +0100, Daniel P. Berrangé wrote: > On Wed, Oct 14, 2020 at 03:19:47PM -0400, Cleber Rosa wrote: > > On Wed, Oct 14, 2020 at 02:59:58PM -0400, Cleber Rosa wrote: > > > On Wed, Oct 14, 2020 at 06:30:09PM +0100, Daniel P. Berrangé wrote: > > > > > > > > This needs updating to add meson, and with Paolo's series today you > > > > might as well go ahead and add ninja-build immediately too > > > > > > > > I replied too quickly, but allow me to get this right: meson is *not* > > included in the dockerfiles (and other similar configurations), and > > all setups I found rely on the submodule. Are suggesting to add meson > > and diverge from the dockerfiles? > > Doh, right, I forgot that we use the submodule for now, since we need > such a new meson. So ignore this... > > > > > https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg04025.html > > > > > > > > ^ I'll add meson according to this, of course. > > Just ninja is needed > Right, I meant ninja there! Thanks, - Cleber.
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 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 | 220 +++++++++++++++++++++++++ scripts/ci/setup/gitlab-runner.yml | 72 ++++++++ scripts/ci/setup/inventory | 2 + scripts/ci/setup/vars.yml.template | 13 ++ 9 files changed, 665 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 -- 2.25.4