2020-03-24 11:01:12 +00:00
|
|
|
variables:
|
2020-03-24 12:04:08 +00:00
|
|
|
GIT_DEPTH: 100
|
2020-03-24 11:01:12 +00:00
|
|
|
|
2020-03-06 15:38:36 +00:00
|
|
|
stages:
|
2020-06-02 15:28:57 +00:00
|
|
|
- containers
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
- builds
|
2021-10-05 09:02:24 +00:00
|
|
|
- integration_tests
|
2020-07-28 09:05:16 +00:00
|
|
|
- sanity_checks
|
2023-04-03 14:02:05 +00:00
|
|
|
- pages
|
2020-03-06 15:38:36 +00:00
|
|
|
|
2020-03-27 15:40:05 +00:00
|
|
|
.script_variables: &script_variables |
|
gitlab: Enable improved ccache usage
Setting CC="ccache cc" works in most cases, but sometimes it will
break the build: in particular, we have experienced issues in the
past with that approach when using cgo to build our Go bindings.
A more robust approach is to have a directory containing symlinks
from the compiler name to the ccache binary: in that case, ccache
itself will invoke the compiler, and the build system will be none
the wiser.
Since libvirt-ci commit 2563aebb6c5c, container images contain a
suitable symlink directory, so all that's needed to enable the new
approach is to add this directory to $PATH.
Since we're touching this anyway, we make a few more changes:
$CCACHE_DIR is no longer created manually, because ccache will
take care of creating it for us if it doesn't already exist; the
ccache setup is moved out of the job template and into
script_variables, removing unnecessary duplication; a limit is
set on the size of the cache (500 MB, which is twice the amount
used by a fresh build on my Fedora 31 machine).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-30 16:29:06 +00:00
|
|
|
export CCACHE_BASEDIR="$(pwd)"
|
|
|
|
export CCACHE_DIR="$CCACHE_BASEDIR/ccache"
|
|
|
|
export CCACHE_MAXSIZE="500M"
|
|
|
|
export PATH="$CCACHE_WRAPPERSDIR:$PATH"
|
2021-05-05 13:44:47 +00:00
|
|
|
export VIR_TEST_VERBOSE="1"
|
|
|
|
export VIR_TEST_DEBUG="1"
|
2020-03-06 15:38:36 +00:00
|
|
|
|
2021-10-05 09:02:24 +00:00
|
|
|
include:
|
|
|
|
- '/ci/gitlab.yml'
|
|
|
|
- '/ci/integration.yml'
|
2020-06-02 15:28:57 +00:00
|
|
|
|
2021-01-13 16:45:06 +00:00
|
|
|
.native_build_job:
|
2024-01-18 15:20:14 +00:00
|
|
|
extends: .gitlab_native_build_job
|
2020-03-25 15:01:43 +00:00
|
|
|
cache:
|
|
|
|
paths:
|
|
|
|
- ccache/
|
|
|
|
key: "$CI_JOB_NAME"
|
2020-03-06 16:29:03 +00:00
|
|
|
script:
|
2023-08-24 14:05:16 +00:00
|
|
|
- source ci/jobs.sh
|
2020-10-08 13:36:07 +00:00
|
|
|
- if test -x /usr/bin/rpmbuild && test "$RPM" != "skip";
|
|
|
|
then
|
2023-08-24 14:05:16 +00:00
|
|
|
run_rpmbuild;
|
2021-05-10 17:14:12 +00:00
|
|
|
else
|
2023-08-24 14:05:16 +00:00
|
|
|
run_build;
|
|
|
|
run_test;
|
2020-10-08 13:36:07 +00:00
|
|
|
fi
|
2023-02-01 10:11:32 +00:00
|
|
|
after_script:
|
|
|
|
- test "$CI_JOB_STATUS" != "success" && exit 1;
|
|
|
|
- if test -x /usr/bin/rpmbuild && test "$RPM" != "skip";
|
|
|
|
then
|
|
|
|
mv "$HOME"/rpmbuild/RPMS/x86_64/ libvirt-rpms/;
|
|
|
|
fi
|
2020-03-06 16:29:03 +00:00
|
|
|
|
2021-01-13 16:45:06 +00:00
|
|
|
.cross_build_job:
|
2024-01-18 15:20:14 +00:00
|
|
|
extends: .gitlab_cross_build_job
|
2020-03-25 15:01:43 +00:00
|
|
|
cache:
|
|
|
|
paths:
|
|
|
|
- ccache/
|
|
|
|
key: "$CI_JOB_NAME"
|
2019-01-25 17:38:53 +00:00
|
|
|
script:
|
2023-08-24 14:05:41 +00:00
|
|
|
- source ci/jobs.sh
|
2023-11-02 10:16:20 +00:00
|
|
|
- if test -x /usr/bin/rpmbuild && test "$RPM" != "skip";
|
2023-08-24 14:05:41 +00:00
|
|
|
then
|
2023-11-02 10:16:20 +00:00
|
|
|
run_rpmbuild;
|
|
|
|
else
|
|
|
|
run_build;
|
|
|
|
if test "$CROSS" = "i686";
|
|
|
|
then
|
|
|
|
run_test;
|
|
|
|
fi;
|
2023-08-24 14:05:41 +00:00
|
|
|
fi
|
2019-01-25 17:38:53 +00:00
|
|
|
|
2020-03-06 14:56:42 +00:00
|
|
|
# This artifact published by this job is downloaded by libvirt.org to
|
|
|
|
# be deployed to the web root:
|
|
|
|
# https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=website
|
2024-01-18 15:20:14 +00:00
|
|
|
website_job:
|
|
|
|
extends: .gitlab_native_build_job
|
|
|
|
needs:
|
|
|
|
- job: x86_64-almalinux-8-container
|
|
|
|
optional: true
|
2020-03-06 14:56:42 +00:00
|
|
|
script:
|
2023-08-24 14:05:41 +00:00
|
|
|
- source ci/jobs.sh
|
|
|
|
- run_website_build
|
2023-02-01 10:11:32 +00:00
|
|
|
after_script:
|
|
|
|
- test "$CI_JOB_STATUS" != "success" && exit 1;
|
2022-07-19 13:21:30 +00:00
|
|
|
- mv install/usr/share/doc/libvirt/html/ website
|
2020-03-06 14:56:42 +00:00
|
|
|
artifacts:
|
|
|
|
expose_as: 'Website'
|
|
|
|
name: 'website'
|
|
|
|
when: on_success
|
|
|
|
expire_in: 30 days
|
|
|
|
paths:
|
|
|
|
- website
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
variables:
|
|
|
|
NAME: almalinux-8
|
2024-01-18 15:20:14 +00:00
|
|
|
TARGET_BASE_IMAGE: docker.io/library/almalinux:8
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
|
2023-04-03 14:02:05 +00:00
|
|
|
# On push to master publish the website from 'website_job' via gitlab pages
|
|
|
|
pages:
|
|
|
|
stage: pages
|
|
|
|
script:
|
|
|
|
- mv website public
|
|
|
|
dependencies:
|
|
|
|
- website_job
|
|
|
|
rules:
|
|
|
|
- if: '$CI_PROJECT_NAMESPACE == $RUN_UPSTREAM_NAMESPACE && $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
|
|
|
|
when: on_success
|
|
|
|
- when: never
|
|
|
|
artifacts:
|
|
|
|
expose_as: 'pages'
|
|
|
|
name: 'pages'
|
|
|
|
paths:
|
|
|
|
- public
|
|
|
|
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
.codestyle_job:
|
|
|
|
stage: sanity_checks
|
|
|
|
needs:
|
2023-05-03 09:09:15 +00:00
|
|
|
- job: x86_64-opensuse-leap-15-container
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
optional: true
|
2024-01-18 15:20:14 +00:00
|
|
|
script:
|
|
|
|
- source ci/jobs.sh
|
|
|
|
- run_codestyle
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
variables:
|
2023-05-03 09:09:15 +00:00
|
|
|
NAME: opensuse-leap-15
|
2024-01-18 15:20:14 +00:00
|
|
|
TARGET_BASE_IMAGE: registry.opensuse.org/opensuse/leap:15.5
|
2020-03-26 12:07:34 +00:00
|
|
|
|
2020-03-24 14:42:14 +00:00
|
|
|
# This artifact published by this job is downloaded to push to Weblate
|
|
|
|
# for translation usage:
|
|
|
|
# https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=potfile
|
|
|
|
potfile:
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
image: $CI_REGISTRY/$RUN_UPSTREAM_NAMESPACE/libvirt/ci-$NAME:latest
|
ci: Reduce number of stages
Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.
This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.
Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.
Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].
[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-10 10:11:30 +00:00
|
|
|
stage: builds
|
2022-10-11 07:27:24 +00:00
|
|
|
variables:
|
|
|
|
NAME: almalinux-8
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
before_script:
|
|
|
|
- cat /packages.txt
|
2020-07-28 09:15:13 +00:00
|
|
|
needs:
|
2022-05-27 11:47:07 +00:00
|
|
|
- job: x86_64-almalinux-8-container
|
|
|
|
optional: true
|
2021-01-14 10:20:36 +00:00
|
|
|
rules:
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
- if: '$CI_PROJECT_NAMESPACE == $RUN_UPSTREAM_NAMESPACE && $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
|
|
|
|
when: on_success
|
|
|
|
- when: never
|
2020-03-27 15:40:05 +00:00
|
|
|
before_script:
|
|
|
|
- *script_variables
|
2020-03-24 14:42:14 +00:00
|
|
|
script:
|
2023-08-24 14:05:41 +00:00
|
|
|
- source ci/jobs.sh
|
|
|
|
- run_potfile
|
2023-02-01 10:11:32 +00:00
|
|
|
after_script:
|
|
|
|
- test "$CI_JOB_STATUS" != "success" && exit 1;
|
2020-06-04 13:26:39 +00:00
|
|
|
- cp po/libvirt.pot libvirt.pot
|
2020-03-24 14:42:14 +00:00
|
|
|
artifacts:
|
|
|
|
expose_as: 'Potfile'
|
|
|
|
name: 'potfile'
|
|
|
|
when: on_success
|
|
|
|
expire_in: 30 days
|
|
|
|
paths:
|
|
|
|
- libvirt.pot
|
2020-03-26 10:46:47 +00:00
|
|
|
|
2020-11-12 13:56:25 +00:00
|
|
|
# Coverity job that is run only by schedules
|
|
|
|
coverity:
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
image: $CI_REGISTRY/$RUN_UPSTREAM_NAMESPACE/libvirt/ci-$NAME:latest
|
|
|
|
stage: builds
|
2020-11-12 13:56:25 +00:00
|
|
|
needs:
|
2022-05-27 11:47:07 +00:00
|
|
|
- job: x86_64-almalinux-8-container
|
|
|
|
optional: true
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
before_script:
|
|
|
|
- cat /packages.txt
|
2020-11-12 13:56:25 +00:00
|
|
|
script:
|
2023-11-21 17:31:40 +00:00
|
|
|
- curl https://scan.coverity.com/download/cxx/linux64 --form project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN -o /tmp/cov-analysis-linux64.tgz
|
2020-11-12 13:56:25 +00:00
|
|
|
- tar xfz /tmp/cov-analysis-linux64.tgz
|
2021-05-10 17:20:30 +00:00
|
|
|
- meson setup build --werror || (cat build/meson-logs/meson-log.txt && exit 1)
|
|
|
|
- cov-analysis-linux64-*/bin/cov-build --dir cov-int meson compile -C build
|
2020-11-12 13:56:25 +00:00
|
|
|
- tar cfz cov-int.tar.gz cov-int
|
|
|
|
- curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME --form token=$COVERITY_SCAN_TOKEN --form email=$GITLAB_USER_EMAIL --form file=@cov-int.tar.gz --form version="$(git describe --tags)" --form description="$(git describe --tags) / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID"
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
variables:
|
|
|
|
NAME: almalinux-8
|
2021-01-14 10:20:36 +00:00
|
|
|
rules:
|
ci: refresh with latest lcitool manifest
This refresh switches the CI for contributors to be triggered by merge
requests. Pushing to a branch in a fork will no longer run CI pipelines,
in order to avoid consuming CI minutes. To regain the original behaviour
contributors can opt-in to a pipeline on push
git push <remote> -o ci.variable=RUN_PIPELINE=1
This variable can also be set globally on the repository, through the
web UI options Settings -> CI/CD -> Variables, though this is not
recommended. Upstream repo pushes to branches will run CI.
The use of containers has changed in this update, with only the upstream
repo creating containers, in order to avoid consuming contributors'
limited storage quotas. A fork with existing container images may delete
them. Containers will be rebuilt upstream when pushing commits with CI
changes to the default branch. Any other scenario with CI changes will
simply install build pre-requisite packages in a throaway environment,
using the ci/buildenv/ scripts. These scripts may also be used on a
contributor's local machines.
With pipelines triggered by merge requests, it is also now possible to
workaround the inability of contributors to run pipelines if they have
run out of CI quota. A project member can trigger a pipeline from the
merge request, which will run in context of upstream, however, note
this should only be done after reviewing the code for any malicious
CI changes.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-09-30 08:50:04 +00:00
|
|
|
- if: '$COVERITY_SCAN_PROJECT_NAME == null || $COVERITY_SCAN_TOKEN == null'
|
|
|
|
when: never
|
|
|
|
- if: '$CI_PROJECT_NAMESPACE == $RUN_UPSTREAM_NAMESPACE && $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH'
|
|
|
|
when: on_success
|
|
|
|
- when: never
|