External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-05 04:41:20 +00:00
Code Issues Packages Projects Releases Wiki Activity
248a30c0c0
libvirt/.gitlab-ci.yml

654 lines
16 KiB
YAML
Raw Normal View History

gitlab: add variable for make command name To facilitate future jobs that will use FreeBSD Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 11:01:12 +00:00
variables:
gitlab: restrict git history to 100 commits We don't need the full git history when running CI jobs. From a code POV we only need the most recent commit, but we want to be able to run checks on the commits too. In particular to validate the DCO signoff for each commit. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 12:04:08 +00:00
GIT_DEPTH: 100
gitlab: add variable for make command name To facilitate future jobs that will use FreeBSD Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 11:01:12 +00:00
gitlab: create an explicit stage for cross build jobs As we introduce more build jobs, it will be useful to have a grouping of jobs to more easily visualize the results and potentially control build ordering. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 15:38:36 +00:00
stages:
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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
ci: move sanity_checks after other stages Be less hostile to developers and run the build jobs even if the dco-check failed. That way they can test their own "private" branches without a sign-off. Also specify empty `needs` for it, since it does not depend on any of the jobs in the container phase and can be run right away. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-28 09:05:16 +00:00
- sanity_checks
gitlab: create an explicit stage for cross build jobs As we introduce more build jobs, it will be useful to have a grouping of jobs to more easily visualize the results and potentially control build ordering. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 15:38:36 +00:00
gitlab: Add script_variables and define $MAKEFLAGS there This new template provides a standardized place where environment variables which are not static, but rather depend on the output of some shell command, can be defined for later use. This pattern is already used in libosinfo's GitLab CI integration. Defining $MAKEFLAGS there means we don't need to call getconf over and over, and the actual build steps don't end up drowned in the noise. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-27 15:40:05 +00:00
.script_variables: &script_variables |
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"
gitlab: enable debug output for test suite When CI jobs fail on the test suite, we don't see much helpful information by default: stderr: TEST: bhyvexml2argvtest ......!!.............!......!........... 40 ........................!...... 71 FAIL Some tests failed. Run them using: VIR_TEST_DEBUG=1 VIR_TEST_RANGE=7-8,22,29,65 /tmp/cirrus-ci-build/build/meson-private/dist-build/tests/bhyvexml2argvtest Following the instructions to re-run the test with VIR_TEST_DEBUG=1 is quite unfriendly when we could have had that set for CI already. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-05 13:44:47 +00:00
export VIR_TEST_VERBOSE="1"
export VIR_TEST_DEBUG="1"
gitlab: create an explicit stage for cross build jobs As we introduce more build jobs, it will be useful to have a grouping of jobs to more easily visualize the results and potentially control build ordering. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 15:38:36 +00:00
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
# Common templates
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
.container_job:
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
image: docker:stable
stage: containers
ci: run container jobs right away The jobs building containers do not depend on anything. Make this explicit by including the 'needs' keyword in case we need to shuffle around the stages in the future. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-31 12:51:00 +00:00
needs: []
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
services:
- docker:dind
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
gitlab-ci.yml: Add an explicit env variable to mark a job as broken Thanks to the 'rules' syntax, this will translate to 'allow_failure:true' and let the job fail but will not affect the rest of the pipeline. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:36:54 +00:00
- if: "$TEMPORARILY_DISABLED"
allow_failure: true
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
- when: on_success
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
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
ci: Drop prefix from Dockerfiles Since the string "ci" is already contained in the path, it seems unnecessary to include it into the filename too: in fact, we only do that for Dockerfiles and not for files in ci/cirrus, even though those are generated the very same way. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2021-03-19 15:04:37 +00:00
- docker build --cache-from "$TAG" --cache-from "$COMMON_TAG" --tag "$TAG" -f "ci/containers/$NAME.Dockerfile" ci/containers
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
- docker push "$TAG"
after_script:
- docker logout
# 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
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
.container_optional_job:
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
allow_failure: true
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
.native_build_job:
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
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
gitlab-ci.yml: Add an explicit env variable to mark a job as broken Thanks to the 'rules' syntax, this will translate to 'allow_failure:true' and let the job fail but will not affect the rest of the pipeline. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:36:54 +00:00
- if: "$TEMPORARILY_DISABLED"
allow_failure: true
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
- when: on_success
gitlab: introduce use of ccache for speeding up rebuilds For any given job there is a high likelihood that ccache will be able to reuse previously built object files. This will result in faster build pipelines in later updates. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-25 15:01:43 +00:00
cache:
paths:
- ccache/
key: "$CI_JOB_NAME"
before_script:
gitlab: Add script_variables and define $MAKEFLAGS there This new template provides a standardized place where environment variables which are not static, but rather depend on the output of some shell command, can be defined for later use. This pattern is already used in libosinfo's GitLab CI integration. Defining $MAKEFLAGS there means we don't need to call getconf over and over, and the actual build steps don't end up drowned in the noise. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-27 15:40:05 +00:00
- *script_variables
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
script:
gitlab: run "meson" directly instead of "ninja" indirection The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:20:30 +00:00
- meson setup build --werror || (cat build/meson-logs/meson-log.txt && exit 1)
gitlab: avoid building libvirt twice and running syntax-check twice In the distros using RPMs, we build libvirt once as a side effect of running "ninja dist", and once via rpmbuild. In addition "ninja dist" will run all tests including the "syntax-check" suite, despite use having a separate "codestyle" job for for that. There is no way to pass "--no-suite" when creating the dist, but if we switch to invoking "meson dist", we can skip the build+test part entirely using "--no-tests". When doing this we then run explicit "meson compile" and "meson test" commands for the distros that don't build the RPMs, and in the latter case we can now skip the "syntax-check" suite. The RPM builds already skipped the "syntax-check" suite. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:14:12 +00:00
- meson dist -C build --no-tests
ci: Start building RPMs We lost this coverage during the move from CentOS CI to GitLab CI, and it's high time we brought it back. Building RPMs is currently skipped for * openSUSE, which is not supported by our spec file; * clang builds, where rpmbuild fails with meson.build:1:0: ERROR: Unable to determine dynamic linker * targets where we install Meson from PyPi, because that doesn't bring in the necessary RPM macros. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 13:36:07 +00:00
- if test -x /usr/bin/rpmbuild && test "$RPM" != "skip";
then
rpmbuild --nodeps -ta build/meson-dist/libvirt-*.tar.xz;
gitlab: avoid building libvirt twice and running syntax-check twice In the distros using RPMs, we build libvirt once as a side effect of running "ninja dist", and once via rpmbuild. In addition "ninja dist" will run all tests including the "syntax-check" suite, despite use having a separate "codestyle" job for for that. There is no way to pass "--no-suite" when creating the dist, but if we switch to invoking "meson dist", we can skip the build+test part entirely using "--no-tests". When doing this we then run explicit "meson compile" and "meson test" commands for the distros that don't build the RPMs, and in the latter case we can now skip the "syntax-check" suite. The RPM builds already skipped the "syntax-check" suite. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:14:12 +00:00
else
meson compile -C build;
meson test -C build --no-suite syntax-check --print-errorlogs;
ci: Start building RPMs We lost this coverage during the move from CentOS CI to GitLab CI, and it's high time we brought it back. Building RPMs is currently skipped for * openSUSE, which is not supported by our spec file; * clang builds, where rpmbuild fails with meson.build:1:0: ERROR: Unable to determine dynamic linker * targets where we install Meson from PyPi, because that doesn't bring in the necessary RPM macros. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 13:36:07 +00:00
fi
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
ci: Enable address and undefined behavior sanitizers meson supports the following sanitizers: "address" (e.g. out-of-bounds memory access, use-after-free, etc.), "thread" (data races), "undefined" (e.g. signed integer overflow), and "memory" (use of uninitialized memory). Note that not all sanitizers are supported by all compilers, and that more sanitizers exist. Not all sanitizers can be enabled at the same time, but "address" and "undefined" can. Both thread and memory sanitizers require an instrumented build of all dependencies, including libc. gcc and clang use different implementations of these sanitizers and have proven to find different issues. Create CI jobs for both. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-05-06 15:08:38 +00:00
.sanitizer_build_job:
stage: builds
image: $CI_REGISTRY_IMAGE/ci-ubuntu-2004:latest
needs:
- x64-ubuntu-2004-container
rules:
- if: "$TEMPORARILY_DISABLED"
allow_failure: true
- when: on_success
cache:
paths:
- ccache/
key: "$CI_JOB_NAME"
before_script:
- *script_variables
script:
gitlab-ci: Don't build docs in 'sanitizer' jobs Docs are not sanitized, thus there's no point in building them. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2021-06-15 15:27:18 +00:00
- meson build --werror -Ddocs=disabled -Db_lundef=false -Db_sanitize="$SANITIZER"
ci: Enable address and undefined behavior sanitizers meson supports the following sanitizers: "address" (e.g. out-of-bounds memory access, use-after-free, etc.), "thread" (data races), "undefined" (e.g. signed integer overflow), and "memory" (use of uninitialized memory). Note that not all sanitizers are supported by all compilers, and that more sanitizers exist. Not all sanitizers can be enabled at the same time, but "address" and "undefined" can. Both thread and memory sanitizers require an instrumented build of all dependencies, including libc. gcc and clang use different implementations of these sanitizers and have proven to find different issues. Create CI jobs for both. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-05-06 15:08:38 +00:00
- ninja -C build;
- ninja -C build test;
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
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: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
#
# The Cirrus CI configuration is generated by replacing target-specific
# variables in a generic template: some of these variables are provided
# when the GitLab CI job is defined, others are taken from a shell
# snippet generated using lcitool.
#
# Note that the $PATH environment variable has to be treated with
# special care, because we can't just override it at the GitLab CI job
# definition level or we risk breaking it completely.
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
.cirrus_build_job:
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
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master
ci: run Cirrus-based builds sooner Jobs using cirrus-run don't need to wait for any jobs from the container stage. Run them as soon as possible. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 23:06:30 +00:00
needs: []
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
script:
ci: rename the cirrus vars file to remove the "libvirt-" prefix The "libvirt-" prefix was removed from hostnames in libvirt-ci. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-11 14:01:51 +00:00
- source ci/cirrus/$NAME.vars
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
- sed -e "s|[@]CI_REPOSITORY_URL@|$CI_REPOSITORY_URL|g"
-e "s|[@]CI_COMMIT_REF_NAME@|$CI_COMMIT_REF_NAME|g"
-e "s|[@]CI_COMMIT_SHA@|$CI_COMMIT_SHA|g"
-e "s|[@]CIRRUS_VM_INSTANCE_TYPE@|$CIRRUS_VM_INSTANCE_TYPE|g"
-e "s|[@]CIRRUS_VM_IMAGE_SELECTOR@|$CIRRUS_VM_IMAGE_SELECTOR|g"
-e "s|[@]CIRRUS_VM_IMAGE_NAME@|$CIRRUS_VM_IMAGE_NAME|g"
ci: Update package list on Cirrus CI While pkgng on FreeBSD updates the package list automatically when it's run, homebrew on macOS doesn't do the same thing, which can result in stale packages being installed. Explicitly call 'brew update' before 'brew install' to avoid that scenario. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-15 14:29:52 +00:00
-e "s|[@]UPDATE_COMMAND@|$UPDATE_COMMAND|g"
ci: Also perform package upgrades on macOS and FreeBSD The base OS image might include outdated contents, and we don't want to get spurious failures caused by bugs that have already been fixed in the respective packages. This is particularly important on macOS, because 'brew install foo' will fail if 'foo' is already installed but outdated: upgrading all packages first ensures we never run into this scenario. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-06-15 08:15:39 +00:00
-e "s|[@]UPGRADE_COMMAND@|$UPGRADE_COMMAND|g"
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
-e "s|[@]INSTALL_COMMAND@|$INSTALL_COMMAND|g"
-e "s|[@]PATH@|$PATH_EXTRA${PATH_EXTRA:+:}\$PATH|g"
-e "s|[@]PKG_CONFIG_PATH@|$PKG_CONFIG_PATH|g"
-e "s|[@]PKGS@|$PKGS|g"
-e "s|[@]MAKE@|$MAKE|g"
-e "s|[@]PYTHON@|$PYTHON|g"
ci: refresh cirrus vars files In this refresh the PIP variable is renamed to PIP3 and the PYPI_PKGS variable disappears since we (currently) don't have any need for it. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-11 14:12:02 +00:00
-e "s|[@]PIP3@|$PIP3|g"
meson: update .gitlab-ci.yml file Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-08-03 06:53:00 +00:00
-e "s|[@]PYPI_PKGS@|$PYPI_PKGS|g"
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
<ci/cirrus/build.yml >ci/cirrus/$NAME.yml
- cat ci/cirrus/$NAME.yml
ci: Temporarily enable verbose mode for cirrus-run We've hit issues with GitLab CI jobs reporting a failure despite the corresponding Cirrus CI job finishing successfully: this is apparently caused by the underlying VM being rescheduled. A workaround for this issue has been implemented as of https://github.com/sio/cirrus-run/commit/5299874bbb71a84bec7476d9d0ca4ba49bb7ed97 which will be included in the upcoming 0.3.0 release; however, in order to validate that this workaround is effective it would be useful to have more data. Based on the conversation in https://github.com/sio/cirrus-run/issues/4 enabling verbose mode allows to collect this data while not having any impact on performance, so let's enable it temporarily and then disable it again once cirrus-run 0.3.0 is out. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-08-04 10:00:41 +00:00
- cirrus-run -v --show-build-log always ci/cirrus/$NAME.yml
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
gitlab-ci.yml: Add an explicit env variable to mark a job as broken Thanks to the 'rules' syntax, this will translate to 'allow_failure:true' and let the job fail but will not affect the rest of the pipeline. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:36:54 +00:00
- if: "$TEMPORARILY_DISABLED"
allow_failure: true
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
- if: "$CIRRUS_GITHUB_REPO && $CIRRUS_API_TOKEN"
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
.cross_build_job:
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
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
image: $CI_REGISTRY_IMAGE/ci-$NAME-cross-$CROSS:latest
gitlab: introduce use of ccache for speeding up rebuilds For any given job there is a high likelihood that ccache will be able to reuse previously built object files. This will result in faster build pipelines in later updates. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-25 15:01:43 +00:00
cache:
paths:
- ccache/
key: "$CI_JOB_NAME"
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
gitlab-ci.yml: Add an explicit env variable to mark a job as broken Thanks to the 'rules' syntax, this will translate to 'allow_failure:true' and let the job fail but will not affect the rest of the pipeline. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:36:54 +00:00
- if: "$TEMPORARILY_DISABLED"
allow_failure: true
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
- when: on_success
gitlab: introduce use of ccache for speeding up rebuilds For any given job there is a high likelihood that ccache will be able to reuse previously built object files. This will result in faster build pipelines in later updates. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-25 15:01:43 +00:00
before_script:
gitlab: Add script_variables and define $MAKEFLAGS there This new template provides a standardized place where environment variables which are not static, but rather depend on the output of some shell command, can be defined for later use. This pattern is already used in libosinfo's GitLab CI integration. Defining $MAKEFLAGS there means we don't need to call getconf over and over, and the actual build steps don't end up drowned in the noise. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-27 15:40:05 +00:00
- *script_variables
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
script:
gitlab: run "meson" directly instead of "ninja" indirection The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:20:30 +00:00
- meson setup build --werror $MESON_OPTS || (cat build/meson-logs/meson-log.txt && exit 1)
- meson compile -C build
gitlab: avoid building libvirt twice and running syntax-check twice In the distros using RPMs, we build libvirt once as a side effect of running "ninja dist", and once via rpmbuild. In addition "ninja dist" will run all tests including the "syntax-check" suite, despite use having a separate "codestyle" job for for that. There is no way to pass "--no-suite" when creating the dist, but if we switch to invoking "meson dist", we can skip the build+test part entirely using "--no-tests". When doing this we then run explicit "meson compile" and "meson test" commands for the distros that don't build the RPMs, and in the latter case we can now skip the "syntax-check" suite. The RPM builds already skipped the "syntax-check" suite. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:14:12 +00:00
- if test "$CROSS" = "i686" ; then meson test -C build --no-suite syntax-check --print-errorlogs ; fi
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
# Native container build jobs
x64-centos-8-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: centos-8
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
x64-centos-stream-8-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
NAME: centos-stream-8
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
x64-debian-10-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10
x64-debian-sid-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid
gitlab: re-generate container images from lcitool This introduces Fedora 33 and removes some redundant packages. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-23 18:03:36 +00:00
x64-fedora-33-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
gitlab: re-generate container images from lcitool This introduces Fedora 33 and removes some redundant packages. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-23 18:03:36 +00:00
NAME: fedora-33
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
ci: Add Fedora 34 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:44:03 +00:00
x64-fedora-34-container:
extends: .container_job
variables:
NAME: fedora-34
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
x64-fedora-rawhide-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: fedora-rawhide
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
x64-opensuse-leap-152-container:
ci: Add openSUSE Leap 15.2 Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-19 07:28:42 +00:00
extends: .container_job
variables:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
NAME: opensuse-leap-152
ci: Add openSUSE Leap 15.2 Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-19 07:28:42 +00:00
ci: Add openSUSE Tumbleweed Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:41:34 +00:00
x64-opensuse-tumbleweed-container:
extends: .container_job
variables:
NAME: opensuse-tumbleweed
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
x64-ubuntu-1804-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: ubuntu-1804
x64-ubuntu-2004-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: ubuntu-2004
# Cross-build containers build jobs
aarch64-debian-10-container:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-aarch64
armv6l-debian-10-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-armv6l
ci: Use correct name for armv7l architecture Turns out 'ldebian' was not a typo, but rather the result of mistakenly shifting the dash in 'armv7l-debian' one spot to the left. Fixes: 821100e81281eef9beeb15c3f4bf6a000d6a03c5 Reported-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2020-07-29 08:53:51 +00:00
armv7l-debian-10-container:
ci: Mark container build jobs as required/optional correctly Whether a container build job is considered required depends on whether the corresponding cross-build job exists, and in a few cases the two got out of sync over time. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:55:37 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-armv7l
i686-debian-10-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-i686
mips-debian-10-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-mips
mips64el-debian-10-container:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-mips64el
mipsel-debian-10-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-mipsel
ppc64le-debian-10-container:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-ppc64le
s390x-debian-10-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-10-cross-s390x
aarch64-debian-sid-container:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-aarch64
armv6l-debian-sid-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-armv6l
ci: Use correct name for armv7l architecture Turns out 'ldebian' was not a typo, but rather the result of mistakenly shifting the dash in 'armv7l-debian' one spot to the left. Fixes: 821100e81281eef9beeb15c3f4bf6a000d6a03c5 Reported-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2020-07-29 08:53:51 +00:00
armv7l-debian-sid-container:
ci: Mark container build jobs as required/optional correctly Whether a container build job is considered required depends on whether the corresponding cross-build job exists, and in a few cases the two got out of sync over time. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:55:37 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-armv7l
i686-debian-sid-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-i686
mips64el-debian-sid-container:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-mips64el
mipsel-debian-sid-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-mipsel
ppc64le-debian-sid-container:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
extends: .container_optional_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-ppc64le
s390x-debian-sid-container:
ci: Mark container build jobs as required/optional correctly Whether a container build job is considered required depends on whether the corresponding cross-build job exists, and in a few cases the two got out of sync over time. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:55:37 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: debian-sid-cross-s390x
mingw32-fedora-rawhide-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: fedora-rawhide-cross-mingw32
mingw64-fedora-rawhide-container:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .container_job
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
NAME: fedora-rawhide-cross-mingw64
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
# Native architecture build + test jobs
x64-debian-10:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-debian-10-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: debian-10
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
x64-debian-10-clang:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-debian-10-container
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
variables:
NAME: debian-10
CC: clang
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
x64-debian-sid:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-debian-sid-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: debian-sid
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
x64-centos-8:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-centos-8-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: centos-8
ci: Start building RPMs We lost this coverage during the move from CentOS CI to GitLab CI, and it's high time we brought it back. Building RPMs is currently skipped for * openSUSE, which is not supported by our spec file; * clang builds, where rpmbuild fails with meson.build:1:0: ERROR: Unable to determine dynamic linker * targets where we install Meson from PyPi, because that doesn't bring in the necessary RPM macros. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 13:36:07 +00:00
RPM: skip
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
x64-centos-8-clang:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-centos-8-container
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
variables:
NAME: centos-8
CC: clang
ci: Start building RPMs We lost this coverage during the move from CentOS CI to GitLab CI, and it's high time we brought it back. Building RPMs is currently skipped for * openSUSE, which is not supported by our spec file; * clang builds, where rpmbuild fails with meson.build:1:0: ERROR: Unable to determine dynamic linker * targets where we install Meson from PyPi, because that doesn't bring in the necessary RPM macros. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 13:36:07 +00:00
RPM: skip
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
x64-centos-stream-8:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
- x64-centos-stream-8-container
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
variables:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
NAME: centos-stream-8
ci: Start building RPMs We lost this coverage during the move from CentOS CI to GitLab CI, and it's high time we brought it back. Building RPMs is currently skipped for * openSUSE, which is not supported by our spec file; * clang builds, where rpmbuild fails with meson.build:1:0: ERROR: Unable to determine dynamic linker * targets where we install Meson from PyPi, because that doesn't bring in the necessary RPM macros. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 13:36:07 +00:00
RPM: skip
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
gitlab: re-generate container images from lcitool This introduces Fedora 33 and removes some redundant packages. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-23 18:03:36 +00:00
x64-fedora-33:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
gitlab: re-generate container images from lcitool This introduces Fedora 33 and removes some redundant packages. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-23 18:03:36 +00:00
- x64-fedora-33-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
gitlab: re-generate container images from lcitool This introduces Fedora 33 and removes some redundant packages. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-23 18:03:36 +00:00
NAME: fedora-33
gitlab: update list of distros to use latest versions Replace Fedora 30 with Fedora 32 Replace Ubuntu 16.04 with Ubuntu 20.04 Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-04 12:06:56 +00:00
ci: Add Fedora 34 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:44:03 +00:00
x64-fedora-34:
extends: .native_build_job
needs:
- x64-fedora-34-container
variables:
NAME: fedora-34
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
x64-fedora-rawhide:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-fedora-rawhide-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: fedora-rawhide
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
x64-fedora-rawhide-clang:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-fedora-rawhide-container
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
variables:
NAME: fedora-rawhide
CC: clang
ci: Start building RPMs We lost this coverage during the move from CentOS CI to GitLab CI, and it's high time we brought it back. Building RPMs is currently skipped for * openSUSE, which is not supported by our spec file; * clang builds, where rpmbuild fails with meson.build:1:0: ERROR: Unable to determine dynamic linker * targets where we install Meson from PyPi, because that doesn't bring in the necessary RPM macros. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 13:36:07 +00:00
RPM: skip
ci: add clang jobs Run the build with clang on Fedora Rawhide, Debian 10 and CentOS 8. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 12:32:40 +00:00
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
x64-opensuse-leap-152:
ci: Add openSUSE Leap 15.2 Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-19 07:28:42 +00:00
extends: .native_build_job
needs:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
- x64-opensuse-leap-152-container
ci: Add openSUSE Leap 15.2 Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-19 07:28:42 +00:00
variables:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
NAME: opensuse-leap-152
ci: Add openSUSE Leap 15.2 Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-19 07:28:42 +00:00
RPM: skip
ci: Add openSUSE Tumbleweed Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:41:34 +00:00
x64-opensuse-tumbleweed:
extends: .native_build_job
needs:
- x64-opensuse-tumbleweed-container
variables:
NAME: opensuse-tumbleweed
RPM: skip
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
x64-ubuntu-1804:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-ubuntu-1804-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: ubuntu-1804
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
gitlab: update list of distros to use latest versions Replace Fedora 30 with Fedora 32 Replace Ubuntu 16.04 with Ubuntu 20.04 Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-04 12:06:56 +00:00
x64-ubuntu-2004:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .native_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-ubuntu-2004-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: ubuntu-2004
gitlab: update list of distros to use latest versions Replace Fedora 30 with Fedora 32 Replace Ubuntu 16.04 with Ubuntu 20.04 Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-04 12:06:56 +00:00
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
x64-freebsd-12-build:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cirrus_build_job
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
variables:
NAME: freebsd-12
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
CIRRUS_VM_IMAGE_SELECTOR: image_family
ci: Build on FreeBSD 12.2 The FreeBSD 12.1 image on Cirrus CI is currently broken, but that's okay because a FreeBSD 12.2 image is also available and we'd rather build on the more up-to-date target anyway. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2021-02-11 11:15:45 +00:00
CIRRUS_VM_IMAGE_NAME: freebsd-12-2
ci: Update package list on Cirrus CI While pkgng on FreeBSD updates the package list automatically when it's run, homebrew on macOS doesn't do the same thing, which can result in stale packages being installed. Explicitly call 'brew update' before 'brew install' to avoid that scenario. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-15 14:29:52 +00:00
UPDATE_COMMAND: pkg update
ci: Also perform package upgrades on macOS and FreeBSD The base OS image might include outdated contents, and we don't want to get spurious failures caused by bugs that have already been fixed in the respective packages. This is particularly important on macOS, because 'brew install foo' will fail if 'foo' is already installed but outdated: upgrading all packages first ensures we never run into this scenario. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-06-15 08:15:39 +00:00
UPGRADE_COMMAND: pkg upgrade -y
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
INSTALL_COMMAND: pkg install -y
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
ci: Add FreeBSD 13 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:43:06 +00:00
x64-freebsd-13-build:
extends: .cirrus_build_job
variables:
NAME: freebsd-13
CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
CIRRUS_VM_IMAGE_SELECTOR: image_family
CIRRUS_VM_IMAGE_NAME: freebsd-13-0
UPDATE_COMMAND: pkg update
ci: Also perform package upgrades on macOS and FreeBSD The base OS image might include outdated contents, and we don't want to get spurious failures caused by bugs that have already been fixed in the respective packages. This is particularly important on macOS, because 'brew install foo' will fail if 'foo' is already installed but outdated: upgrading all packages first ensures we never run into this scenario. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-06-15 08:15:39 +00:00
UPGRADE_COMMAND: pkg upgrade -y
ci: Add FreeBSD 13 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:43:06 +00:00
INSTALL_COMMAND: pkg install -y
ci: Build on macOS 11 instead of macOS 10.15 macOS builder capacity on Cirrus CI is quite limited, and so we can't afford to keep the old build job around after adding the new one like we do for FreeBSD. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-15 14:13:39 +00:00
x64-macos-11-build:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cirrus_build_job
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
variables:
ci: Build on macOS 11 instead of macOS 10.15 macOS builder capacity on Cirrus CI is quite limited, and so we can't afford to keep the old build job around after adding the new one like we do for FreeBSD. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-15 14:13:39 +00:00
NAME: macos-11
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
CIRRUS_VM_INSTANCE_TYPE: osx_instance
CIRRUS_VM_IMAGE_SELECTOR: image
ci: Build on macOS 11 instead of macOS 10.15 macOS builder capacity on Cirrus CI is quite limited, and so we can't afford to keep the old build job around after adding the new one like we do for FreeBSD. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-15 14:13:39 +00:00
CIRRUS_VM_IMAGE_NAME: big-sur-base
ci: Update package list on Cirrus CI While pkgng on FreeBSD updates the package list automatically when it's run, homebrew on macOS doesn't do the same thing, which can result in stale packages being installed. Explicitly call 'brew update' before 'brew install' to avoid that scenario. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-15 14:29:52 +00:00
UPDATE_COMMAND: brew update
ci: Also perform package upgrades on macOS and FreeBSD The base OS image might include outdated contents, and we don't want to get spurious failures caused by bugs that have already been fixed in the respective packages. This is particularly important on macOS, because 'brew install foo' will fail if 'foo' is already installed but outdated: upgrading all packages first ensures we never run into this scenario. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-06-15 08:15:39 +00:00
UPGRADE_COMMAND: brew upgrade
cirrus: Generate jobs dynamically Instead of having static job definitions for FreeBSD and macOS, use a generic template for both and fill in the details that are actually different, such as the list of packages to install, in the GitLab CI job, right before calling cirrus-run. The target-specific information are provided by lcitool, so that keeping them up to date is just a matter of running the refresh script when necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-29 17:00:36 +00:00
INSTALL_COMMAND: brew install
PATH_EXTRA: /usr/local/opt/ccache/libexec:/usr/local/opt/gettext/bin:/usr/local/opt/libpcap/bin:/usr/local/opt/libxslt/bin:/usr/local/opt/rpcgen/bin
PKG_CONFIG_PATH: /usr/local/opt/curl/lib/pkgconfig:/usr/local/opt/libpcap/lib/pkgconfig:/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/ncurses/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig
ci: Enable Cirrus CI integration We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs, making it possible to extend our platform coverage to include FreeBSD without having to maintain our own runners; additionally, we'll be able to ditch Travis CI and, since results for Cirrus CI jobs are reflected back to the GitLab CI jobs that triggered them, we will be able to get all information from a single dashboard. The FreeBSD and macOS job definitions can be improved further: for example, we will want to enable caching to speed up builds, and ultimately we should figure out a way to generate at least part of them, notably the list of packages to be installed, using lcitool. All of that will happen in later patches: for now, this is good enough to start using Cirrus CI. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-05 18:37:55 +00:00
gitlab: add x86_64 native CI jobs This patch adds x86_64 native CI jobs for all distros that we currently build container images for. This is a superset of the Linux jobs run on current Jenkins and Travis platforms. The remaining missing platforms are FreeBSD and macOS, neither of which can use the shared runner container based infrastructure. We may add further native jobs in the future which are not x86_64 based, if we get access to suitable hardware, thus the jobs all have an arch prefix in their name, just like the cross-built jobs do. As with the cross-arch builds, the native jobs are split into two groups. One group is run in all situations, while the other group is only run on the master branch, or branches with a name prefix 'ci-full-'. This avoids the build time getting too long when developers are testing their code prior to submission, while keeping full coverage of code that is merged. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 16:29:03 +00:00
# Cross compiled build jobs
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
aarch64-debian-sid:
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
extends: .cross_build_job
needs:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
- aarch64-debian-sid-container
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
variables:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
NAME: debian-sid
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
CROSS: aarch64
ci: Drop Debian 9 jobs The existing cross-compilation jobs are carefully redistributed among Debian 10 and Debian sid to ensure we don't use the latter for aarch64, mipsel or mips64el, since those architectures are currently broken. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-14 16:49:41 +00:00
armv6l-debian-10:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- armv6l-debian-10-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
ci: Drop Debian 9 jobs The existing cross-compilation jobs are carefully redistributed among Debian 10 and Debian sid to ensure we don't use the latter for aarch64, mipsel or mips64el, since those architectures are currently broken. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-14 16:49:41 +00:00
NAME: debian-10
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
CROSS: armv6l
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
meson: .gitlab-ci.yml: switch armv7l build to Debian 10 On Debian Sid there are broken headers for cross compilation. There is no <asm/kvm.h> header unconditionally included by <linux/kvm.h>. With autotools the build works correctly because the header detection tries to compile simple code that includes the header but with Meson the detection works differently. We check <linux/kvm.h> which is present so it should be safe to include it. We could workaround it in libvirt by checking for presence of <asm/kvm.h> as well but I don't believe that's a correct approach. IMHO it should be fixed in Debian. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-16 08:26:02 +00:00
armv7l-debian-10:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- armv7l-debian-10-container
meson: .gitlab-ci.yml: switch armv7l build to Debian 10 On Debian Sid there are broken headers for cross compilation. There is no <asm/kvm.h> header unconditionally included by <linux/kvm.h>. With autotools the build works correctly because the header detection tries to compile simple code that includes the header but with Meson the detection works differently. We check <linux/kvm.h> which is present so it should be safe to include it. We could workaround it in libvirt by checking for presence of <asm/kvm.h> as well but I don't believe that's a correct approach. IMHO it should be fixed in Debian. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-16 08:26:02 +00:00
variables:
NAME: debian-10
CROSS: armv7l
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
i686-debian-sid:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
- i686-debian-sid-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
NAME: debian-sid
CROSS: i686
gitlab: Perform some builds on Debian 10 The split is mostly arbitrary, but we purposefully moved the mips64el builds off sid since currently that container is failing to build and is thus unavailable. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-11 10:34:50 +00:00
ci: Drop Debian 9 jobs The existing cross-compilation jobs are carefully redistributed among Debian 10 and Debian sid to ensure we don't use the latter for aarch64, mipsel or mips64el, since those architectures are currently broken. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-14 16:49:41 +00:00
mips-debian-10:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- mips-debian-10-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
ci: Drop Debian 9 jobs The existing cross-compilation jobs are carefully redistributed among Debian 10 and Debian sid to ensure we don't use the latter for aarch64, mipsel or mips64el, since those architectures are currently broken. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-14 16:49:41 +00:00
NAME: debian-10
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
CROSS: mips
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
mips64el-debian-sid:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
- mips64el-debian-sid-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
NAME: debian-sid
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
CROSS: mips64el
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
ci: Swap mipsel and ppc64le builds Debian sid is currently broken on mipsel, so use Debian 10 for that architecture; at the same time, move the ppc64le build from Debian 10 to Debian sid to keep things balanced. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2020-06-11 18:06:02 +00:00
mipsel-debian-10:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- mipsel-debian-10-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: debian-10
ci: Swap mipsel and ppc64le builds Debian sid is currently broken on mipsel, so use Debian 10 for that architecture; at the same time, move the ppc64le build from Debian 10 to Debian sid to keep things balanced. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2020-06-11 18:06:02 +00:00
CROSS: mipsel
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
ppc64le-debian-10:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
- ppc64le-debian-10-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
ci: Move ppc64le build from Debian sid to Debian 10 Debian sid is currently broken on ppc64le, so move the build to Debian 10; do the opposite for the aarch64 and mips64el builds to try and restore the 10/sid balance. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:45:53 +00:00
NAME: debian-10
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
CROSS: ppc64le
tests: perform cross compiler builds on GitLab CI GitLab CI provides some shared build runners that use Docker containers. This resource can usefully run cross-compiled builds since all other CI build testing is currently x86 only, and Travis CI is already very busy testing native builds. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-25 17:38:53 +00:00
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
s390x-debian-sid:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
- s390x-debian-sid-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: debian-sid
ci: Shuffle cross-building jobs around Keep them ordered by architecture, the same way the corresponding container jobs are, to make it easier to jump between the two sections and compare them. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 11:57:51 +00:00
CROSS: s390x
gitlab: use CI for building website contents Run the bare minimum build that is possible to create the docs, avoiding compiling code which other jobs will deal with. The generated website is published as an artifact and thus is browsable by developers on build completion and can be downloaded as a zip file. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 14:56:42 +00:00
gitlab: update list of distros to use latest versions Replace Fedora 30 with Fedora 32 Replace Ubuntu 16.04 with Ubuntu 20.04 Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-04 12:06:56 +00:00
mingw32-fedora-rawhide:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- mingw32-fedora-rawhide-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: fedora-rawhide
CROSS: mingw32
gitlab: add mingw cross build CI jobs This pulls in the mingw cross build jobs using Fedora 30 as a base, matching what is done on Jenkins and Travis. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 14:23:27 +00:00
gitlab: update list of distros to use latest versions Replace Fedora 30 with Fedora 32 Replace Ubuntu 16.04 with Ubuntu 20.04 Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-04 12:06:56 +00:00
mingw64-fedora-rawhide:
gitlab-ci.yml: Replace template anchors with extends 'extends' is slightly more readable and definitely more flexible in terms of allowing includes of templates. The main reason for this patch though is that the next patch converts the 'only/except' syntax to the new (preferable) 'rules' syntax. Variable anchors are still kept intact because the use case there is different from regular template anchors. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-13 16:45:06 +00:00
extends: .cross_build_job
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- mingw64-fedora-rawhide-container
ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:55 +00:00
variables:
NAME: fedora-rawhide
CROSS: mingw64
gitlab: add mingw cross build CI jobs This pulls in the mingw cross build jobs using Fedora 30 as a base, matching what is done on Jenkins and Travis. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 14:23:27 +00:00
ci: Enable address and undefined behavior sanitizers meson supports the following sanitizers: "address" (e.g. out-of-bounds memory access, use-after-free, etc.), "thread" (data races), "undefined" (e.g. signed integer overflow), and "memory" (use of uninitialized memory). Note that not all sanitizers are supported by all compilers, and that more sanitizers exist. Not all sanitizers can be enabled at the same time, but "address" and "undefined" can. Both thread and memory sanitizers require an instrumented build of all dependencies, including libc. gcc and clang use different implementations of these sanitizers and have proven to find different issues. Create CI jobs for both. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-05-06 15:08:38 +00:00
# Sanitizers
sanitize-gcc:
extends: .sanitizer_build_job
variables:
ASAN_OPTIONS: verify_asan_link_order=0
CC: gcc
SANITIZER: address,undefined
sanitize-clang:
extends: .sanitizer_build_job
variables:
CC: clang
SANITIZER: address,undefined
gitlab: add mingw cross build CI jobs This pulls in the mingw cross build jobs using Fedora 30 as a base, matching what is done on Jenkins and Travis. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 14:23:27 +00:00
gitlab: use CI for building website contents Run the bare minimum build that is possible to create the docs, avoiding compiling code which other jobs will deal with. The generated website is published as an artifact and thus is browsable by developers on build completion and can be downloaded as a zip file. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
image: $CI_REGISTRY_IMAGE/ci-centos-8:latest
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-centos-8-container
gitlab: Add script_variables and define $MAKEFLAGS there This new template provides a standardized place where environment variables which are not static, but rather depend on the output of some shell command, can be defined for later use. This pattern is already used in libosinfo's GitLab CI integration. Defining $MAKEFLAGS there means we don't need to call getconf over and over, and the actual build steps don't end up drowned in the noise. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-27 15:40:05 +00:00
before_script:
- *script_variables
gitlab: use CI for building website contents Run the bare minimum build that is possible to create the docs, avoiding compiling code which other jobs will deal with. The generated website is published as an artifact and thus is browsable by developers on build completion and can be downloaded as a zip file. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 14:56:42 +00:00
script:
gitlab: run "meson" directly instead of "ninja" indirection The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:20:30 +00:00
- meson setup build --werror --prefix=$(pwd)/vroot || (cat build/meson-logs/meson-log.txt && exit 1)
meson: update .gitlab-ci.yml file Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-08-03 06:53:00 +00:00
- ninja -C build install-web
gitlab: use CI for building website contents Run the bare minimum build that is possible to create the docs, avoiding compiling code which other jobs will deal with. The generated website is published as an artifact and thus is browsable by developers on build completion and can be downloaded as a zip file. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 14:56:42 +00:00
- mv vroot/share/doc/libvirt/html/ website
artifacts:
expose_as: 'Website'
name: 'website'
when: on_success
expire_in: 30 days
paths:
- website
gitlab: add job for building latest potfile Whenever there is a change to the translatable strings we need to push a new libvirt.pot to weblate. This only needs to be done when code merges into git master, so the job is restricted to that branch. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 14:42:14 +00:00
gitlab: add explicit early job for syntax-check Running the code style syntax-check as part of the build jobs leads to all jobs failing in the same way. Have a prebuild job for validating syntax-check to catch code style problems upfront and thus avoid needing to run all the build jobs. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>a Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
image: $CI_REGISTRY_IMAGE/ci-opensuse-leap-152:latest
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
ci: Rename CentOS Stream 8 and openSUSE Leap 15.2 containers The names have been recently changed in libvirt-ci to be more accurate, so we should follow along. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-04 08:31:38 +00:00
- x64-opensuse-leap-152-container
gitlab: Add script_variables and define $MAKEFLAGS there This new template provides a standardized place where environment variables which are not static, but rather depend on the output of some shell command, can be defined for later use. This pattern is already used in libosinfo's GitLab CI integration. Defining $MAKEFLAGS there means we don't need to call getconf over and over, and the actual build steps don't end up drowned in the noise. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-27 15:40:05 +00:00
before_script:
- *script_variables
gitlab: add explicit early job for syntax-check Running the code style syntax-check as part of the build jobs leads to all jobs failing in the same way. Have a prebuild job for validating syntax-check to catch code style problems upfront and thus avoid needing to run all the build jobs. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>a Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-26 12:07:34 +00:00
script:
gitlab: run "meson" directly instead of "ninja" indirection The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:20:30 +00:00
- meson setup build --werror || (cat build/meson-logs/meson-log.txt && exit 1)
meson: update .gitlab-ci.yml file Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-08-03 06:53:00 +00:00
- ninja -C build libvirt-pot-dep
gitlab: only print failed tests in codestyle job "meson test" will only print a list of which tests fail by default, so we were sending the full test log to stdout on failure. This makes it really hard to see the errors though as the test log has all succcesful tests too. "ninja test" will print the same as "meson test", following by details of each failure. It does this using the "--print-errorlog" flag, so lets use that in the codestyle job. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 16:57:50 +00:00
- meson test -C build --suite syntax-check --no-rebuild --print-errorlogs
gitlab: add explicit early job for syntax-check Running the code style syntax-check as part of the build jobs leads to all jobs failing in the same way. Have a prebuild job for validating syntax-check to catch code style problems upfront and thus avoid needing to run all the build jobs. Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>a Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-26 12:07:34 +00:00
gitlab: add job for building latest potfile Whenever there is a change to the translatable strings we need to push a new libvirt.pot to weblate. This only needs to be done when code merges into git master, so the job is restricted to that branch. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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
ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 15:28:57 +00:00
image: $CI_REGISTRY_IMAGE/ci-centos-8:latest
ci: specify containter dependencies for all the jobs Write down the container job needed for each build job in the 'needs' keyword to allow greater parallelism. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-28 09:15:13 +00:00
needs:
- x64-centos-8-container
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
- if: "$CI_COMMIT_BRANCH == 'master'"
gitlab: Add script_variables and define $MAKEFLAGS there This new template provides a standardized place where environment variables which are not static, but rather depend on the output of some shell command, can be defined for later use. This pattern is already used in libosinfo's GitLab CI integration. Defining $MAKEFLAGS there means we don't need to call getconf over and over, and the actual build steps don't end up drowned in the noise. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-27 15:40:05 +00:00
before_script:
- *script_variables
gitlab: add job for building latest potfile Whenever there is a change to the translatable strings we need to push a new libvirt.pot to weblate. This only needs to be done when code merges into git master, so the job is restricted to that branch. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 14:42:14 +00:00
script:
gitlab: run "meson" directly instead of "ninja" indirection The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:20:30 +00:00
- meson setup build --werror || (cat build/meson-logs/meson-log.txt && exit 1)
meson: update .gitlab-ci.yml file Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-08-03 06:53:00 +00:00
- ninja -C build libvirt-pot-dep
- ninja -C build libvirt-pot
gitlab: fix potfile job for new location Since we're storing the libvirt.pot file in git now, we should pull from the source dir, not the build dir. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-04 13:26:39 +00:00
- cp po/libvirt.pot libvirt.pot
gitlab: add job for building latest potfile Whenever there is a change to the translatable strings we need to push a new libvirt.pot to weblate. This only needs to be done when code merges into git master, so the job is restricted to that branch. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-24 14:42:14 +00:00
artifacts:
expose_as: 'Potfile'
name: 'potfile'
when: on_success
expire_in: 30 days
paths:
- libvirt.pot
gitlab: introduce a check for validate DCO sign-off This introduces a CI job for validating DCO sign-off in every commit message. The CI jobs are not provided any information on what the baseline commit for the branch was. We can't compare against the forked repo's master branch, as there's no guarantee the user is keeping master up2date in their fork. Thus we add the master upstream repo as a git remote and identify the common ancestor. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-26 10:46:47 +00:00
gitlab: convert to shared container for DCO check This removes the locally maintained DCO checking script in favour of the shared container image provided by libvirt-ci.git. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
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
ci: move sanity_checks after other stages Be less hostile to developers and run the build jobs even if the dco-check failed. That way they can test their own "private" branches without a sign-off. Also specify empty `needs` for it, since it does not depend on any of the jobs in the container phase and can be run right away. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-28 09:05:16 +00:00
needs: []
gitlab: convert to shared container for DCO check This removes the locally maintained DCO checking script in favour of the shared container image provided by libvirt-ci.git. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-01 10:57:33 +00:00
image: registry.gitlab.com/libvirt/libvirt-ci/check-dco:master
gitlab: introduce a check for validate DCO sign-off This introduces a CI job for validating DCO sign-off in every commit message. The CI jobs are not provided any information on what the baseline commit for the branch was. We can't compare against the forked repo's master branch, as there's no guarantee the user is keeping master up2date in their fork. Thus we add the master upstream repo as a git remote and identify the common ancestor. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-26 10:46:47 +00:00
script:
gitlab: convert to shared container for DCO check This removes the locally maintained DCO checking script in favour of the shared container image provided by libvirt-ci.git. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-01 10:57:33 +00:00
- /check-dco
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
- if: "$CI_PROJECT_NAMESPACE != 'libvirt'"
meson: ci: increase git clone depth to 1000 Having limit set to 100 is in most cases perfect but sometimes there can be a larger series that will have more than 100 patches and it will make the check-dco job fail. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com>
2020-07-14 14:29:26 +00:00
variables:
GIT_DEPTH: 1000
gitlab-ci: add coverity job Introduce new job to make a coverity build and upload coverity data to scan.coverity.com where the analysis is then executed. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-12 13:56:25 +00:00
# Coverity job that is run only by schedules
coverity:
image: $CI_REGISTRY_IMAGE/ci-centos-8:latest
needs:
- x64-centos-8-container
stage: builds
script:
- curl https://scan.coverity.com/download/linux64 --form project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN -o /tmp/cov-analysis-linux64.tgz
- tar xfz /tmp/cov-analysis-linux64.tgz
gitlab: run "meson" directly instead of "ninja" indirection The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-05-10 17:20:30 +00:00
- meson setup build --werror || (cat build/meson-logs/meson-log.txt && exit 1)
- cov-analysis-linux64-*/bin/cov-build --dir cov-int meson compile -C build
gitlab-ci: add coverity job Introduce new job to make a coverity build and upload coverity data to scan.coverity.com where the analysis is then executed. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-12 13:56:25 +00:00
- tar cfz cov-int.tar.gz cov-int
- curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN --form email=$GITLAB_USER_EMAIL --form file=@cov-int.tar.gz --form version="$(git describe --tags)" --form description="$(git describe --tags) / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID"
gitlab-ci.yml: Convert only/except to the rules syntax 'rules' syntax replaces the only/except syntax with which it is mutually exclusive. In some cases the 'rules' syntax is more readable than the 'only/except' equivalent, in some cases it is not. The idea behind this conversion is to introduce an explicit env variable controlling the 'allow_failure' attribute which would then be attached to a broken build job which would in turn result in a soft failure. Such behaviour is not possible to achieve with the older 'only/except' syntax. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2021-01-14 10:20:36 +00:00
rules:
- if: "$CI_PIPELINE_SOURCE == 'schedule' && $COVERITY_SCAN_PROJECT_NAME && $COVERITY_SCAN_TOKEN"
Reference in New Issue Copy Permalink