shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
3bfa9fce51
libvirt/.gitlab-ci.yml

620 lines
15 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 14:01:12 +03: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 15:04:08 +03: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 14:01:12 +03: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 18:38:36 +03: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 18:28:57 +03: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 13:11:30 +03: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 12:05:16 +03: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 18:38:36 +03: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 18:40:05 +03: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 19:29:06 +03:00
export CCACHE_BASEDIR="$(pwd)"
export CCACHE_DIR="$CCACHE_BASEDIR/ccache"
export CCACHE_MAXSIZE="500M"
export PATH="$CCACHE_WRAPPERSDIR:$PATH"
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 18:38:36 +03: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 19:29:03 +03: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 19:45:06 +03: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 18:28:57 +03: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 15:51:00 +03: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 18:28:57 +03: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 13:20:36 +03: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 13:36:54 +03: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 13:20:36 +03: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 18:28:57 +03: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
gitlab: replace "libvirt-" prefix with "ci-" in dockerfiles This makes the dockerfile name match the output container name Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-12-01 18:22:09 +03:00
- docker build --cache-from "$TAG" --cache-from "$COMMON_TAG" --tag "$TAG" -f "ci/containers/ci-$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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 13:11:30 +03: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 18:28:57 +03: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 13:20:36 +03: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 13:36:54 +03: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 13:20:36 +03: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 18:01:43 +03: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 18:40:05 +03: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 19:29:03 +03:00
script:
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 09:53:00 +03:00
- meson build --werror || (cat build/meson-logs/meson-log.txt && exit 1)
ci: Allow skipping dist Instead of having an ad-hoc build script for CentOS 7, follow the pattern established in other repositories under the libvirt group and allow selectively disabling that specific part of the build. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 16:30:50 +03:00
- if test "$DIST" != "skip";
then
ninja -C build dist;
else
ninja -C build;
ninja -C build test;
fi
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 16:36:07 +03:00
- if test -x /usr/bin/rpmbuild && test "$RPM" != "skip";
then
rpmbuild --nodeps -ta build/meson-dist/libvirt-*.tar.xz;
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 19:29:03 +03: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 21:37:55 +03: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 20:00:36 +03: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 19:45:06 +03: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 13:11:30 +03: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 21:37:55 +03: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-29 02:06:30 +03: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 21:37:55 +03: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 17:01:51 +03: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 20:00:36 +03: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"
-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 17:12:02 +03: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 09:53:00 +03: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 20:00:36 +03: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 13:00:41 +03: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 13:20:36 +03: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 13:36:54 +03: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 13:20:36 +03: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 21:37:55 +03: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 19:45:06 +03: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 13:11:30 +03: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 18:28:57 +03: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 18:01:43 +03: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 13:20:36 +03: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 13:36:54 +03: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 13:20:36 +03: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 18:01:43 +03: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 18:40:05 +03: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 20:38:53 +03:00
script:
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 09:53:00 +03:00
- meson build --werror $MESON_OPTS || (cat build/meson-logs/meson-log.txt && exit 1)
- ninja -C build
gitlab: run unit tests in i686 cross build In most cross builds we can't run tests since we can't assume QEMU user mode emulators are loaded. i686 is special though because x86_64 can run i686 natively, so we should run unit tests there. The key benefit is that this gives us 32-bit unit test coverage in CI. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-10-29 20:32:28 +03:00
- if test "$CROSS" = "i686" ; then ninja -C build test ; 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 20:38:53 +03: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 18:28:57 +03:00
# Native container build jobs
x64-centos-7-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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: centos-7
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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: centos-8
x64-centos-stream-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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: centos-stream
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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 21:03:36 +03:00
x64-fedora-32-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 19:45:06 +03: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 18:28:57 +03: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 21:03:36 +03:00
NAME: fedora-32
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 18:28:57 +03: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 21:03:36 +03: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 19:45:06 +03: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 18:28:57 +03: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 21:03:36 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: fedora-rawhide
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 10:28:42 +03:00
x64-opensuse-152-container:
extends: .container_job
variables:
NAME: opensuse-152
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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: ubuntu-2004
# Cross-build containers build jobs
aarch64-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 11:53:51 +03:00
armv7l-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: debian-10-cross-mips
mips64el-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: debian-10-cross-mipsel
ppc64le-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: debian-10-cross-s390x
aarch64-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 11:53:51 +03:00
armv7l-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: debian-sid-cross-i686
mips64el-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: debian-sid-cross-mipsel
ppc64le-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 19:45:06 +03: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 18:28:57 +03:00
variables:
NAME: debian-sid-cross-ppc64le
s390x-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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 19:45:06 +03: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 18:28:57 +03: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 19:29:03 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 19:29:03 +03: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 15:32:40 +03: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 19:45:06 +03: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 12:15:13 +03: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 15:32:40 +03: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 19:29:03 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 19:29:03 +03:00
x64-centos-7:
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 19:45:06 +03: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 12:15:13 +03:00
needs:
- x64-centos-7-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 18:28:55 +03:00
variables:
NAME: centos-7
ci: Allow skipping dist Instead of having an ad-hoc build script for CentOS 7, follow the pattern established in other repositories under the libvirt group and allow selectively disabling that specific part of the build. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-08 16:30:50 +03:00
# meson dist fails on CentOS 7 because of old git that fails to clone
# from shallow git repository which is done when running meson dist
DIST: skip
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 16:36:07 +03: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 19:29:03 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 16:36:07 +03: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 19:29:03 +03: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 15:32:40 +03: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 19:45:06 +03: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 12:15:13 +03: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 15:32:40 +03: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 16:36:07 +03: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 15:32:40 +03: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 18:28:57 +03:00
x64-centos-stream:
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 19:45:06 +03: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 12:15:13 +03:00
needs:
- x64-centos-stream-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 18:28:57 +03:00
variables:
NAME: centos-stream
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 16:36:07 +03: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 18:28:57 +03: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 21:03:36 +03:00
x64-fedora-32:
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 19:45:06 +03: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 12:15:13 +03: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 21:03:36 +03:00
- x64-fedora-32-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 18:28:55 +03: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 21:03:36 +03:00
NAME: fedora-32
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 16:36:07 +03: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 19:29:03 +03: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 21:03:36 +03: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 19:45:06 +03: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 12:15:13 +03: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 21:03:36 +03: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 18:28:55 +03: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 21:03:36 +03: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 15:06:56 +03: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 19:29:03 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03:00
variables:
NAME: fedora-rawhide
gitlab: force dwarf4 format for debuginfo in Fedora rawhide Fedora 34 rawhide has pulled in a new GCC 11 build which now defaults to dwarf5 format. This format is not compatible with the pdwtags program used in our test suite to validate the RPC files. We have no need for debuginfo in CI except for pdwtags, so the simplest short term fix is to force the older dwarf version in the hope that a fixed dwarves release will arrive before Fedora 34 is released, or GCC 11 becomes more widespread. Eventually we might need to figure out a way to probe for compatibility but for now, we'll hope that any distro with GCC 11 will be able to have a fixed dwarves too. https://bugzilla.redhat.com/show_bug.cgi?id=1919965 Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-25 21:13:57 +03:00
# Temp workaround until we see what resolution is for
# https://bugzilla.redhat.com/show_bug.cgi?id=1919965
# Hopefully remove before F34 is released.
CFLAGS: -gdwarf-4
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 19:29:03 +03: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 15:32:40 +03: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 19:45:06 +03: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 12:15:13 +03: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 15:32:40 +03: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 16:36:07 +03: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 15:32:40 +03:00
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 10:28:42 +03:00
x64-opensuse-152:
extends: .native_build_job
needs:
- x64-opensuse-152-container
variables:
NAME: opensuse-152
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 19:29:03 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 19:29:03 +03: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 15:06:56 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 15:06:56 +03:00
Add FreeBSD 11.4 CI job on Cirrus The previous 11.3 image provided by Cirrus did not boot, but they have now provided a working 11.4 image Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-04 13:22:16 +03:00
x64-freebsd-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 19:45:06 +03:00
extends: .cirrus_build_job
Add FreeBSD 11.4 CI job on Cirrus The previous 11.3 image provided by Cirrus did not boot, but they have now provided a working 11.4 image Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-09-04 13:22:16 +03:00
variables:
NAME: freebsd-11
CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
CIRRUS_VM_IMAGE_SELECTOR: image_family
CIRRUS_VM_IMAGE_NAME: freebsd-11-4
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 21:37:55 +03: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 19:45:06 +03: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 21:37:55 +03: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 20:00:36 +03:00
CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
CIRRUS_VM_IMAGE_SELECTOR: image_family
CIRRUS_VM_IMAGE_NAME: freebsd-12-1
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 21:37:55 +03:00
x64-macos-1015-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 19:45:06 +03: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 21:37:55 +03:00
variables:
NAME: macos-1015
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 20:00:36 +03:00
CIRRUS_VM_INSTANCE_TYPE: osx_instance
CIRRUS_VM_IMAGE_SELECTOR: image
CIRRUS_VM_IMAGE_NAME: catalina-base
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 21:37:55 +03: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 19:29:03 +03:00
# Cross compiled build jobs
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 19:49:41 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 19:49:41 +03: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 18:28:55 +03: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 20:38:53 +03: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 11:26:02 +03: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 19:45:06 +03: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 12:15:13 +03: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 11:26:02 +03:00
variables:
NAME: debian-10
CROSS: armv7l
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 19:49:41 +03:00
mips64el-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 19:45:06 +03: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 12:15:13 +03:00
needs:
- mips64el-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 18:28:55 +03: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 19:49:41 +03: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 18:28:55 +03:00
CROSS: mips64el
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 13:34:50 +03: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 19:49:41 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 19:49:41 +03: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 18:28:55 +03: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 20:38:53 +03:00
gitlab: rename the cross build jobs The pipeline UI will truncate the names of jobs after about 15 characters. As a result with the cross-builds, we truncate the most important part of the job name. Putting the most important part first is robust against truncation, and we can drop the redundant "-cross" stub. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <skultety.erik@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 21:34:45 +03:00
aarch64-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 19:45:06 +03: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 12:15:13 +03:00
needs:
- aarch64-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 18:28:55 +03:00
variables:
NAME: debian-10
CROSS: aarch64
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 20:38:53 +03: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 21:06:02 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 21:06:02 +03: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 20:38:53 +03: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 19:49:41 +03: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 19:45:06 +03: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 12:15:13 +03:00
needs:
gitlab: Fix build container dependencies for build jobs A couple of these were wrong, resulting in the build job not waiting for the correct container to be built before starting. Fixes: 77296c807b18d22286be4b0ba5595d13103910a1 Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2021-02-09 12:26:55 +03: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 18:28:55 +03: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 19:49:41 +03:00
NAME: debian-sid
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 18:28:55 +03:00
CROSS: s390x
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 20:38:53 +03:00
gitlab: rename the cross build jobs The pipeline UI will truncate the names of jobs after about 15 characters. As a result with the cross-builds, we truncate the most important part of the job name. Putting the most important part first is robust against truncation, and we can drop the redundant "-cross" stub. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <skultety.erik@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-06 21:34:45 +03: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 19:45:06 +03: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 12:15:13 +03:00
needs:
- 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 18:28:55 +03:00
variables:
NAME: debian-sid
CROSS: i686
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 20:38:53 +03: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 21:06:02 +03:00
ppc64le-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 19:45:06 +03: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 12:15:13 +03:00
needs:
gitlab: Fix build container dependencies for build jobs A couple of these were wrong, resulting in the build job not waiting for the correct container to be built before starting. Fixes: 77296c807b18d22286be4b0ba5595d13103910a1 Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2021-02-09 12:26:55 +03:00
- ppc64le-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 18:28:55 +03:00
variables:
NAME: debian-sid
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 21:06:02 +03:00
CROSS: ppc64le
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 17:56:42 +03: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 15:06:56 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 17:23:27 +03: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 15:06:56 +03: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 19:45:06 +03: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 12:15:13 +03: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 18:28:55 +03: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 17:23:27 +03: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 17:56:42 +03: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 13:11:30 +03: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 18:28:57 +03: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 12:15:13 +03: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 18:40:05 +03: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 17:56:42 +03:00
script:
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 09:53:00 +03:00
- meson build --prefix=$(pwd)/vroot || (cat build/meson-logs/meson-log.txt && exit 1)
- 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 17:56:42 +03: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 17:42:14 +03: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 15:07:34 +03: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 13:11:30 +03:00
stage: builds
ci: Drop openSUSE Leap 15.1 Leap 15.1 will reach EOL on January 31st 2021, so we should not test on it during the current development cycle ending on March 1st. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-20 10:06:35 +03:00
image: $CI_REGISTRY_IMAGE/ci-opensuse-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 12:15:13 +03:00
needs:
ci: Drop openSUSE Leap 15.1 Leap 15.1 will reach EOL on January 31st 2021, so we should not test on it during the current development cycle ending on March 1st. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-20 10:06:35 +03:00
- x64-opensuse-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 18:40:05 +03: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 15:07:34 +03:00
script:
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 09:53:00 +03:00
- meson build || (cat build/meson-logs/meson-log.txt && exit 1)
- ninja -C build libvirt-pot-dep
- meson test -C build --suite syntax-check --no-rebuild || (cat build/meson-logs/testlog.txt && exit 1)
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 15:07:34 +03: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 17:42:14 +03: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 13:11:30 +03: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 18:28:57 +03: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 12:15:13 +03: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 13:20:36 +03: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 18:40:05 +03: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 17:42:14 +03:00
script:
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 09:53:00 +03:00
- meson build || (cat build/meson-logs/meson-log.txt && exit 1)
- 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 16:26:39 +03: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 17:42:14 +03: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 13:46:47 +03: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 13:57:33 +03: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 13:11:30 +03: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 12:05:16 +03: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 13:57:33 +03: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 13:46:47 +03: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 13:57:33 +03: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 13:20:36 +03: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 17:29:26 +03: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 16:56:25 +03: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
- meson build
- cov-analysis-linux64-*/bin/cov-build --dir cov-int ninja -C build
- 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 13:20:36 +03:00
rules:
- if: "$CI_PIPELINE_SOURCE == 'schedule' && $COVERITY_SCAN_PROJECT_NAME && $COVERITY_SCAN_TOKEN"
Copy Permalink