External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-08 22:39:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
17fe7ae0cb
libvirt/ci/integration.yml

83 lines
2.2 KiB
YAML
Raw Normal View History

ci: Separate the integration job template to a separate file Future patches will do more code extraction from the existing template using YAML anchors so it'd be better that the templates would live separately from job definitions. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-06 06:16:46 +00:00
include:
- 'ci/integration-template.yml'
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
centos-stream-8-tests:
ci: rename integration test template Although we split out jobs across many files, the template / job namespace is global, so we should use something more specific than '.tests' as the template name. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2022-03-17 16:29:51 +00:00
extends: .integration_tests
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
needs:
- x86_64-centos-stream-8
- project: libvirt/libvirt-perl
job: x86_64-centos-stream-8
ref: master
artifacts: true
variables:
# needed by libvirt-gitlab-executor
DISTRO: centos-stream-8
Fix spelling Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2022-03-30 14:45:04 +00:00
# can be overridden in forks to set a different runner tag
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
tags:
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
- $LIBVIRT_CI_INTEGRATION_RUNNER_TAG
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
centos-stream-9-tests:
ci: rename integration test template Although we split out jobs across many files, the template / job namespace is global, so we should use something more specific than '.tests' as the template name. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2022-03-17 16:29:51 +00:00
extends: .integration_tests
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
needs:
- x86_64-centos-stream-9
- project: libvirt/libvirt-perl
job: x86_64-centos-stream-9
ref: master
artifacts: true
variables:
# needed by libvirt-gitlab-executor
DISTRO: centos-stream-9
Fix spelling Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2022-03-30 14:45:04 +00:00
# can be overridden in forks to set a different runner tag
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
tags:
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
- $LIBVIRT_CI_INTEGRATION_RUNNER_TAG
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
fedora-34-tests:
ci: rename integration test template Although we split out jobs across many files, the template / job namespace is global, so we should use something more specific than '.tests' as the template name. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2022-03-17 16:29:51 +00:00
extends: .integration_tests
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
needs:
- x86_64-fedora-34
- project: libvirt/libvirt-perl
job: x86_64-fedora-34
ref: master
artifacts: true
variables:
# needed by libvirt-gitlab-executor
DISTRO: fedora-34
Fix spelling Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2022-03-30 14:45:04 +00:00
# can be overridden in forks to set a different runner tag
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
tags:
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
- $LIBVIRT_CI_INTEGRATION_RUNNER_TAG
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
fedora-35-tests:
ci: rename integration test template Although we split out jobs across many files, the template / job namespace is global, so we should use something more specific than '.tests' as the template name. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2022-03-17 16:29:51 +00:00
extends: .integration_tests
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
needs:
- x86_64-fedora-35
- project: libvirt/libvirt-perl
job: x86_64-fedora-35
ref: master
artifacts: true
variables:
# needed by libvirt-gitlab-executor
DISTRO: fedora-35
Fix spelling Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2022-03-30 14:45:04 +00:00
# can be overridden in forks to set a different runner tag
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host
gitlab-ci: Introduce new 'integration_tests' pipeline stage This stage will download build artifacts from both the libvirt and libvirt-perl (multi-project CI) builds, install all them on the custom runners and configures libvirt debug logging on the runners prior to executing the actual test suite. In case of a failure, libvirt and Avocado logs will be saved and published as pipeline artifacts. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-10-05 09:02:24 +00:00
tags:
ci: Define the integration job tag dynamically via a variable Custom runners are private to a project, so naturally forks cannot run any workloads on these. The integration test suite which requires access to our custom runner is naturally disabled on forks and can be enabled by setting LIBVIRT_CI_INTEGRATION=1. The problem is that the current integration jobs definitions have tags statically defined as 'redhat-vm-host'. If users are going to supply their own private runners for their forks, they can define whatever tags they want with it and so unless they add 'redhat-vm-host' to their own runner's tags, the pipeline won't run. To solve this, define the integration job tag using a variable. The repo config will use the value defined in the job for the variable while users can override the value easily on a project/pipeline level thanks to GitLab's CI variable precedence [1]. [1] https://docs.gitlab.com/ee/ci/variables/#cicd-variable-precedence Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-03-21 12:51:53 +00:00
- $LIBVIRT_CI_INTEGRATION_RUNNER_TAG
ci: Add a Fedora integration test job utilizing upstream QEMU Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2022-05-06 13:24:56 +00:00
fedora-35-upstream-qemu-tests:
extends: .integration_tests_upstream_qemu
needs:
- x86_64-fedora-35
- project: libvirt/libvirt-perl
job: x86_64-fedora-35
ref: master
artifacts: true
variables:
# needed by libvirt-gitlab-executor
DISTRO: fedora-35
# can be overridden in forks to set a different runner tag
LIBVIRT_CI_INTEGRATION_RUNNER_TAG: redhat-vm-host
tags:
- $LIBVIRT_CI_INTEGRATION_RUNNER_TAG
Reference in New Issue Copy Permalink