[libvirt-python PATCH v2 2/3] gitlab: introduce CI jobs testing git master & distro libvirt

[Andrea Bolognani]

On Thu, 2020-04-30 at 15:14 +0100, Daniel P. Berrangé wrote:
> +++ b/.gitlab-ci.yml
> @@ -0,0 +1,171 @@
> +
> +stages:
> +  - prebuild
> +  - containers
> +  - build

Should this stage be called "builds", just like the previous one is
called "containers"?

I'm also thinking whether it would be interesting to have a two
separate "dist_builds" and "git_builds" stages, just like we have
a stage for native builds and another one for cross builds in
libvirt.

All of this is just me thinking out loud. I'm happy enough with the
current solution :)

> +.build_git_job_template: &build_git_job_definition
> +  stage: build
> +  before_script:
> +    - export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
> +    - export SCRATCH_DIR="/tmp/scratch"
> +    - export VROOT="$SCRATCH_DIR/vroot"
> +    - export LD_LIBRARY_PATH="$VROOT/lib"
> +    - export PATH="$PATH:$VROOT/bin"

$VROOT/bin should go first, to make sure we use the binaries we just
built and not the ones from the distro packags.

> +  script:
> +    - pushd "$PWD"
> +    - mkdir -p "$SCRATCH_DIR"
> +    - cd "$SCRATCH_DIR"
> +    - git clone --depth 1 https://gitlab.com/libvirt/libvirt.git src
> +    - mkdir build
> +    - cd build
> +    - ../src/autogen.sh --prefix="$VROOT" --without-libvirtd

I'd just let 'git clone' do its own thing here, especially since for
projects like libvirt-dbus that have multiple dependencies when
building from source we'll need to differentiate them.

> +fedora-30-container:
> +  <<: *container_job_definition
> +  variables:
> +    NAME: fedora-30

As you already mentioned, this should be replaced with fedora-32...

> +ubuntu-1604-container:
> +  <<: *container_job_definition
> +  variables:
> +    NAME: ubuntu-1604

... and this with ubuntu-2004.

> +centos-8-build-git:
> +  <<: *build_git_job_definition
> +  image: $CI_REGISTRY_IMAGE/ci-centos-8:latest

We could invert the two parts of the suffix, in the interest of
having the most relevant piece of information first, and call
this centos-8-git-build...

> +centos-7-build-dist:
> +  <<: *build_dist_job_definition
> +  image: $CI_REGISTRY_IMAGE/ci-centos-7:latest

and all the other ones *-dist-build.

Regarless, you can use the same trick used for container jobs also
for build jobs: that is, tweak the templates above so that they look
like

  .build_dist_job_template: &build_dist_job_definition
    stage: build
    image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
    ...

  .build_git_job_template: &build_git_job_definition
    stage: build
    image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
    ...

and then redefine the build jobs as

  centos-8-build-git:
    <<: *build_git_job_definition
    variables:
      NAME: centos-8

  centos-7-build-dist:
    <<: *build_dist_job_definition
    variables:
      NAME: centos-7

and so on.

Test pipeline to prove this actually works:

  https://gitlab.com/abologna/libvirt-python/pipelines/141549490

> +++ b/ci/README.rst
> @@ -0,0 +1,12 @@
> +CI job assets
> +=============
> +
> +This directory contains assets used in the automated CI jobs, most
> +notably the Dockerfiles used to build container images in which the
> +CI jobs then run.
> +
> +The `refresh` script is used to re-create the Dockerfiles

Monospace in reStructuredText looks ``like this``, not `like this`.

> using the `lcitool` that is provided by

s/that/command that/ or s/that/script that/

> repo `https://gitlab.com/libvirt/libvirt-ci`

Remove the backticks and this will be a clickable link. Then leave
a blank line between this and the next paragraph.

-- 
Andrea Bolognani / Red Hat / Virtualization