2020-03-24 11:01:12 +00:00
|
|
|
variables:
|
2020-03-24 12:04:08 +00:00
|
|
|
GIT_DEPTH: 100
|
2020-03-24 11:01:12 +00:00
|
|
|
|
2020-03-06 15:38:36 +00:00
|
|
|
stages:
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
- sanity_checks
|
2020-06-02 15:28:57 +00:00
|
|
|
- containers
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
- builds
|
2020-03-06 15:38:36 +00:00
|
|
|
|
2020-03-27 15:40:05 +00:00
|
|
|
.script_variables: &script_variables |
|
|
|
|
export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
|
gitlab: Enable improved ccache usage
Setting CC="ccache cc" works in most cases, but sometimes it will
break the build: in particular, we have experienced issues in the
past with that approach when using cgo to build our Go bindings.
A more robust approach is to have a directory containing symlinks
from the compiler name to the ccache binary: in that case, ccache
itself will invoke the compiler, and the build system will be none
the wiser.
Since libvirt-ci commit 2563aebb6c5c, container images contain a
suitable symlink directory, so all that's needed to enable the new
approach is to add this directory to $PATH.
Since we're touching this anyway, we make a few more changes:
$CCACHE_DIR is no longer created manually, because ccache will
take care of creating it for us if it doesn't already exist; the
ccache setup is moved out of the job template and into
script_variables, removing unnecessary duplication; a limit is
set on the size of the cache (500 MB, which is twice the amount
used by a fresh build on my Fedora 31 machine).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-30 16:29:06 +00:00
|
|
|
export CCACHE_BASEDIR="$(pwd)"
|
|
|
|
export CCACHE_DIR="$CCACHE_BASEDIR/ccache"
|
|
|
|
export CCACHE_MAXSIZE="500M"
|
|
|
|
export PATH="$CCACHE_WRAPPERSDIR:$PATH"
|
2020-03-06 15:38:36 +00:00
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
# Common templates
|
|
|
|
|
2020-06-02 15:28:57 +00:00
|
|
|
# Containers that are necessary for the default pipeline
|
|
|
|
.container_default_job_template: &container_default_job_definition
|
|
|
|
image: docker:stable
|
|
|
|
stage: containers
|
|
|
|
services:
|
|
|
|
- docker:dind
|
|
|
|
before_script:
|
|
|
|
- export TAG="$CI_REGISTRY_IMAGE/ci-$NAME:latest"
|
|
|
|
- export COMMON_TAG="$CI_REGISTRY/libvirt/libvirt/ci-$NAME:latest"
|
|
|
|
- docker info
|
|
|
|
- docker login registry.gitlab.com -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD"
|
|
|
|
script:
|
|
|
|
- docker pull "$TAG" || docker pull "$COMMON_TAG" || true
|
|
|
|
- docker build --cache-from "$TAG" --cache-from "$COMMON_TAG" --tag "$TAG" -f "ci/containers/libvirt-$NAME.Dockerfile" ci/containers
|
|
|
|
- docker push "$TAG"
|
|
|
|
after_script:
|
|
|
|
- docker logout
|
|
|
|
|
|
|
|
# Containers that are only needed for the full pipeline
|
|
|
|
.container_extra_job_template: &container_extra_job_definition
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
only:
|
|
|
|
- master
|
|
|
|
- /^ci-full-.*$/
|
|
|
|
|
|
|
|
# We build many containers which can be useful to debug problems but are not
|
|
|
|
# needed for the pipeline itself to complete: those sometimes fail, and when
|
|
|
|
# that happens it's mostly because of temporary issues with Debian sid. We
|
|
|
|
# don't want those failures to affect the overall pipeline status
|
|
|
|
.container_optional_job_template: &container_optional_job_definition
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
allow_failure: true
|
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
# Default native build jobs that are always run
|
|
|
|
.native_build_default_job_template: &native_build_default_job_definition
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2020-06-02 15:28:57 +00:00
|
|
|
image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
|
2020-03-25 15:01:43 +00:00
|
|
|
cache:
|
|
|
|
paths:
|
|
|
|
- ccache/
|
|
|
|
key: "$CI_JOB_NAME"
|
|
|
|
before_script:
|
2020-03-27 15:40:05 +00:00
|
|
|
- *script_variables
|
2020-03-06 16:29:03 +00:00
|
|
|
script:
|
|
|
|
- mkdir build
|
|
|
|
- cd build
|
|
|
|
- ../autogen.sh || (cat config.log && exit 1)
|
2020-03-27 15:40:05 +00:00
|
|
|
- $MAKE distcheck
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
# Extra native build jobs that are only run post-merge, or
|
|
|
|
# when code is pushed to a branch with "ci-full-" name prefix
|
|
|
|
.native_build_extra_job_template: &native_build_extra_job_definition
|
|
|
|
<<: *native_build_default_job_definition
|
|
|
|
only:
|
|
|
|
- master
|
|
|
|
- /^ci-full-.*$/
|
|
|
|
|
2020-06-05 18:37:55 +00:00
|
|
|
# Jobs that we delegate to Cirrus CI because they require an operating
|
|
|
|
# system other than Linux. These jobs will only run if the required
|
|
|
|
# setup has been performed on the GitLab account (see ci/README.rst).
|
|
|
|
.cirrus_build_default_job_template: &cirrus_build_default_job_definition
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2020-06-05 18:37:55 +00:00
|
|
|
image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master
|
|
|
|
script:
|
|
|
|
- cirrus-run ci/cirrus/$NAME.yml.j2
|
|
|
|
only:
|
|
|
|
variables:
|
|
|
|
- $CIRRUS_GITHUB_REPO
|
|
|
|
- $CIRRUS_API_TOKEN
|
|
|
|
|
|
|
|
.cirrus_build_extra_job_template: &cirrus_build_extra_job_definition
|
|
|
|
<<: *cirrus_build_default_job_definition
|
|
|
|
only:
|
|
|
|
variables:
|
|
|
|
- $CIRRUS_GITHUB_REPO
|
|
|
|
- $CIRRUS_API_TOKEN
|
|
|
|
refs:
|
|
|
|
- master
|
|
|
|
- /^ci-full-.*$/
|
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
|
2020-03-25 13:14:57 +00:00
|
|
|
# Default cross build jobs that are always run
|
2020-03-06 15:38:36 +00:00
|
|
|
.cross_build_default_job_template: &cross_build_default_job_definition
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2020-06-02 15:28:57 +00:00
|
|
|
image: $CI_REGISTRY_IMAGE/ci-$NAME-cross-$CROSS:latest
|
2020-03-25 15:01:43 +00:00
|
|
|
cache:
|
|
|
|
paths:
|
|
|
|
- ccache/
|
|
|
|
key: "$CI_JOB_NAME"
|
|
|
|
before_script:
|
2020-03-27 15:40:05 +00:00
|
|
|
- *script_variables
|
2019-01-25 17:38:53 +00:00
|
|
|
script:
|
|
|
|
- mkdir build
|
|
|
|
- cd build
|
|
|
|
- ../autogen.sh $CONFIGURE_OPTS || (cat config.log && exit 1)
|
2020-03-27 15:40:05 +00:00
|
|
|
- $MAKE
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-25 13:14:57 +00:00
|
|
|
# Extra cross build jobs that are only run post-merge, or
|
|
|
|
# when code is pushed to a branch with "ci-full-" name prefix
|
|
|
|
.cross_build_extra_job_template: &cross_build_extra_job_definition
|
|
|
|
<<: *cross_build_default_job_definition
|
|
|
|
only:
|
|
|
|
- master
|
|
|
|
- /^ci-full-.*$/
|
|
|
|
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-06-02 15:28:57 +00:00
|
|
|
# Native container build jobs
|
|
|
|
|
|
|
|
x64-centos-7-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: centos-7
|
|
|
|
|
|
|
|
x64-centos-8-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: centos-8
|
|
|
|
|
|
|
|
x64-centos-stream-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: centos-stream
|
|
|
|
|
|
|
|
x64-debian-9-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9
|
|
|
|
|
|
|
|
x64-debian-10-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10
|
|
|
|
|
|
|
|
x64-debian-sid-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid
|
|
|
|
|
|
|
|
x64-fedora-31-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: fedora-31
|
|
|
|
|
|
|
|
x64-fedora-32-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: fedora-32
|
|
|
|
|
|
|
|
x64-fedora-rawhide-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: fedora-rawhide
|
|
|
|
|
|
|
|
x64-opensuse-151-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: opensuse-151
|
|
|
|
|
|
|
|
x64-ubuntu-1804-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: ubuntu-1804
|
|
|
|
|
|
|
|
x64-ubuntu-2004-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: ubuntu-2004
|
|
|
|
|
|
|
|
|
|
|
|
# Cross-build containers build jobs
|
|
|
|
|
|
|
|
aarch64-debian-9-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-aarch64
|
|
|
|
|
|
|
|
armv6l-debian-9-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-armv6l
|
|
|
|
|
|
|
|
armv7l-debian-9-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-armv7l
|
|
|
|
|
|
|
|
mips-debian-9-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-mips
|
|
|
|
|
|
|
|
mips64el-debian-9-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-mips64el
|
|
|
|
|
|
|
|
mipsel-debian-9-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-mipsel
|
|
|
|
|
|
|
|
ppc64le-debian-9-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-ppc64le
|
|
|
|
|
|
|
|
s390x-debian-9-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-9-cross-s390x
|
|
|
|
|
|
|
|
aarch64-debian-10-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-aarch64
|
|
|
|
|
|
|
|
armv6l-debian-10-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-armv6l
|
|
|
|
|
|
|
|
armv7-ldebian-10-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-armv7l
|
|
|
|
|
|
|
|
i686-debian-10-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-i686
|
|
|
|
|
|
|
|
mips-debian-10-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-mips
|
|
|
|
|
|
|
|
mips64el-debian-10-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-mips64el
|
|
|
|
|
|
|
|
mipsel-debian-10-container:
|
2020-06-11 18:06:02 +00:00
|
|
|
<<: *container_extra_job_definition
|
2020-06-02 15:28:57 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-mipsel
|
|
|
|
|
|
|
|
ppc64le-debian-10-container:
|
2020-06-11 18:06:02 +00:00
|
|
|
<<: *container_optional_job_definition
|
2020-06-02 15:28:57 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-ppc64le
|
|
|
|
|
|
|
|
s390x-debian-10-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-10-cross-s390x
|
|
|
|
|
|
|
|
aarch64-debian-sid-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-aarch64
|
|
|
|
|
|
|
|
armv6l-debian-sid-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-armv6l
|
|
|
|
|
|
|
|
armv7-ldebian-sid-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-armv7l
|
|
|
|
|
|
|
|
i686-debian-sid-container:
|
|
|
|
<<: *container_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-i686
|
|
|
|
|
|
|
|
mips-debian-sid-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-mips
|
|
|
|
|
|
|
|
mips64el-debian-sid-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-mips64el
|
|
|
|
|
|
|
|
mipsel-debian-sid-container:
|
2020-06-11 18:06:02 +00:00
|
|
|
<<: *container_optional_job_definition
|
2020-06-02 15:28:57 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-mipsel
|
|
|
|
|
|
|
|
ppc64le-debian-sid-container:
|
2020-06-11 18:06:02 +00:00
|
|
|
<<: *container_extra_job_definition
|
2020-06-02 15:28:57 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-ppc64le
|
|
|
|
|
|
|
|
s390x-debian-sid-container:
|
|
|
|
<<: *container_optional_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: debian-sid-cross-s390x
|
|
|
|
|
|
|
|
mingw32-fedora-rawhide-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: fedora-rawhide-cross-mingw32
|
|
|
|
|
|
|
|
mingw64-fedora-rawhide-container:
|
|
|
|
<<: *container_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: fedora-rawhide-cross-mingw64
|
|
|
|
|
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
# Native architecture build + test jobs
|
|
|
|
|
|
|
|
x64-debian-9:
|
|
|
|
<<: *native_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-9
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
x64-debian-10:
|
|
|
|
<<: *native_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-10
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
x64-debian-sid:
|
|
|
|
<<: *native_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-sid
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
x64-centos-7:
|
|
|
|
<<: *native_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: centos-7
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
x64-centos-8:
|
|
|
|
<<: *native_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: centos-8
|
2020-03-06 16:29:03 +00:00
|
|
|
|
2020-06-02 15:28:57 +00:00
|
|
|
x64-centos-stream:
|
|
|
|
<<: *native_build_extra_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: centos-stream
|
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
x64-fedora-31:
|
|
|
|
<<: *native_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: fedora-31
|
2020-03-06 16:29:03 +00:00
|
|
|
|
2020-05-04 12:06:56 +00:00
|
|
|
x64-fedora-32:
|
|
|
|
<<: *native_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: fedora-32
|
2020-05-04 12:06:56 +00:00
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
x64-fedora-rawhide:
|
|
|
|
<<: *native_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: fedora-rawhide
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
x64-opensuse-151:
|
|
|
|
<<: *native_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: opensuse-151
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
x64-ubuntu-1804:
|
|
|
|
<<: *native_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: ubuntu-1804
|
2020-03-06 16:29:03 +00:00
|
|
|
|
2020-05-04 12:06:56 +00:00
|
|
|
x64-ubuntu-2004:
|
|
|
|
<<: *native_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: ubuntu-2004
|
2020-05-04 12:06:56 +00:00
|
|
|
|
2020-06-05 18:37:55 +00:00
|
|
|
x64-freebsd-12-build:
|
|
|
|
<<: *cirrus_build_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: freebsd-12
|
|
|
|
|
|
|
|
x64-macos-1015-build:
|
|
|
|
<<: *cirrus_build_default_job_definition
|
|
|
|
variables:
|
|
|
|
NAME: macos-1015
|
|
|
|
|
2020-03-06 16:29:03 +00:00
|
|
|
|
|
|
|
# Cross compiled build jobs
|
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
armv6l-debian-9:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-9
|
|
|
|
CROSS: armv6l
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
mips64el-debian-9:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-9
|
|
|
|
CROSS: mips64el
|
2019-07-11 10:34:50 +00:00
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
mips-debian-9:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-9
|
|
|
|
CROSS: mips
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
aarch64-debian-10:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-10
|
|
|
|
CROSS: aarch64
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-06-11 18:06:02 +00:00
|
|
|
mipsel-debian-10:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-10
|
2020-06-11 18:06:02 +00:00
|
|
|
CROSS: mipsel
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
s390x-debian-10:
|
2020-03-06 15:38:36 +00:00
|
|
|
<<: *cross_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-10
|
|
|
|
CROSS: s390x
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
armv7l-debian-sid:
|
2020-03-06 15:38:36 +00:00
|
|
|
<<: *cross_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-sid
|
|
|
|
CROSS: armv7l
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-06 18:34:45 +00:00
|
|
|
i686-debian-sid:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-sid
|
|
|
|
CROSS: i686
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-06-11 18:06:02 +00:00
|
|
|
ppc64le-debian-sid:
|
2020-03-25 13:14:57 +00:00
|
|
|
<<: *cross_build_extra_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: debian-sid
|
2020-06-11 18:06:02 +00:00
|
|
|
CROSS: ppc64le
|
2020-03-06 14:56:42 +00:00
|
|
|
|
2020-05-04 12:06:56 +00:00
|
|
|
mingw32-fedora-rawhide:
|
2020-03-24 14:23:27 +00:00
|
|
|
<<: *cross_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: fedora-rawhide
|
|
|
|
CROSS: mingw32
|
2020-03-24 14:23:27 +00:00
|
|
|
|
2020-05-04 12:06:56 +00:00
|
|
|
mingw64-fedora-rawhide:
|
2020-03-24 14:23:27 +00:00
|
|
|
<<: *cross_build_default_job_definition
|
2020-06-02 15:28:55 +00:00
|
|
|
variables:
|
|
|
|
NAME: fedora-rawhide
|
|
|
|
CROSS: mingw64
|
2020-03-24 14:23:27 +00:00
|
|
|
|
|
|
|
|
2020-03-06 14:56:42 +00:00
|
|
|
# This artifact published by this job is downloaded by libvirt.org to
|
|
|
|
# be deployed to the web root:
|
|
|
|
# https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=website
|
|
|
|
website:
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2020-06-02 15:28:57 +00:00
|
|
|
image: $CI_REGISTRY_IMAGE/ci-centos-8:latest
|
2020-03-27 15:40:05 +00:00
|
|
|
before_script:
|
|
|
|
- *script_variables
|
2020-03-06 14:56:42 +00:00
|
|
|
script:
|
|
|
|
- mkdir build
|
|
|
|
- cd build
|
|
|
|
- ../autogen.sh --prefix=$(pwd)/../vroot || (cat config.log && exit 1)
|
2020-03-27 15:40:05 +00:00
|
|
|
- $MAKE -C docs
|
|
|
|
- $MAKE -C docs install
|
2020-03-06 14:56:42 +00:00
|
|
|
- cd ..
|
|
|
|
- mv vroot/share/doc/libvirt/html/ website
|
|
|
|
artifacts:
|
|
|
|
expose_as: 'Website'
|
|
|
|
name: 'website'
|
|
|
|
when: on_success
|
|
|
|
expire_in: 30 days
|
|
|
|
paths:
|
|
|
|
- website
|
2020-03-24 14:42:14 +00:00
|
|
|
|
|
|
|
|
2020-03-26 12:07:34 +00:00
|
|
|
codestyle:
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2020-06-02 15:28:57 +00:00
|
|
|
image: $CI_REGISTRY_IMAGE/ci-centos-8:latest
|
2020-03-27 15:40:05 +00:00
|
|
|
before_script:
|
|
|
|
- *script_variables
|
2020-03-26 12:07:34 +00:00
|
|
|
script:
|
|
|
|
- mkdir build
|
|
|
|
- cd build
|
|
|
|
- ../autogen.sh || (cat config.log && exit 1)
|
2020-03-27 15:40:05 +00:00
|
|
|
- $MAKE syntax-check
|
2020-03-26 12:07:34 +00:00
|
|
|
|
|
|
|
|
2020-03-24 14:42:14 +00:00
|
|
|
# This artifact published by this job is downloaded to push to Weblate
|
|
|
|
# for translation usage:
|
|
|
|
# https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=potfile
|
|
|
|
potfile:
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2020-06-02 15:28:57 +00:00
|
|
|
image: $CI_REGISTRY_IMAGE/ci-centos-8:latest
|
2020-03-24 14:42:14 +00:00
|
|
|
only:
|
|
|
|
- master
|
2020-03-27 15:40:05 +00:00
|
|
|
before_script:
|
|
|
|
- *script_variables
|
2020-03-24 14:42:14 +00:00
|
|
|
script:
|
|
|
|
- mkdir build
|
|
|
|
- cd build
|
|
|
|
- ../autogen.sh || (cat config.log && exit 1)
|
2020-03-27 15:40:05 +00:00
|
|
|
- $MAKE -C src generated-sources
|
|
|
|
- $MAKE -C po libvirt.pot
|
2020-03-24 14:42:14 +00:00
|
|
|
- cd ..
|
2020-06-04 13:26:39 +00:00
|
|
|
- cp po/libvirt.pot libvirt.pot
|
2020-03-24 14:42:14 +00:00
|
|
|
artifacts:
|
|
|
|
expose_as: 'Potfile'
|
|
|
|
name: 'potfile'
|
|
|
|
when: on_success
|
|
|
|
expire_in: 30 days
|
|
|
|
paths:
|
|
|
|
- libvirt.pot
|
2020-03-26 10:46:47 +00:00
|
|
|
|
|
|
|
|
2020-05-01 10:57:33 +00:00
|
|
|
# Check that all commits are signed-off for the DCO.
|
|
|
|
# Skip on "libvirt" namespace, since we only need to run
|
|
|
|
# this test on developer's personal forks from which
|
|
|
|
# merge requests are submitted
|
|
|
|
check-dco:
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: sanity_checks
|
2020-05-01 10:57:33 +00:00
|
|
|
image: registry.gitlab.com/libvirt/libvirt-ci/check-dco:master
|
2020-03-26 10:46:47 +00:00
|
|
|
script:
|
2020-05-01 10:57:33 +00:00
|
|
|
- /check-dco
|
2020-03-26 10:46:47 +00:00
|
|
|
except:
|
2020-05-01 10:57:33 +00:00
|
|
|
variables:
|
|
|
|
- $CI_PROJECT_NAMESPACE == 'libvirt'
|