libvirt/ci/integration.yml

202 lines
5.2 KiB
YAML
Raw Normal View History

include:
- 'ci/integration-template.yml'
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
.centos-stream-8-tests:
variables:
# needed by libvirt-gitlab-executor
DISTRO: centos-stream-8
# 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
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
centos-stream-8-tests-prebuilt-env:
extends:
- .integration_tests_prebuilt_env
- .centos-stream-8-tests
needs:
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
- x86_64-centos-stream-8-prebuilt-env
- project: libvirt/libvirt-perl
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
job: x86_64-centos-stream-8-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-centos-stream-8-prebuilt-env
ref: master
artifacts: 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
centos-stream-8-tests-local-env:
extends:
- .integration_tests_local_env
- .centos-stream-8-tests
needs:
- x86_64-centos-stream-8-local-env
- project: libvirt/libvirt-perl
job: x86_64-centos-stream-8-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-centos-stream-8-prebuilt-env
ref: master
artifacts: 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
.centos-stream-9-tests:
variables:
# needed by libvirt-gitlab-executor
DISTRO: centos-stream-9
# 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
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
centos-stream-9-tests-prebuilt-env:
extends:
- .integration_tests_prebuilt_env
- .centos-stream-9-tests
needs:
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
- x86_64-centos-stream-9-prebuilt-env
- project: libvirt/libvirt-perl
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
job: x86_64-centos-stream-9-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-centos-stream-9-prebuilt-env
ref: master
artifacts: 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
centos-stream-9-tests-local-env:
extends:
- .integration_tests_local_env
- .centos-stream-9-tests
needs:
- x86_64-centos-stream-9-local-env
- project: libvirt/libvirt-perl
job: x86_64-centos-stream-9-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-centos-stream-9-prebuilt-env
ref: master
artifacts: 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
.fedora-35-tests:
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
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
fedora-35-tests-prebuilt-env:
extends:
- .integration_tests_prebuilt_env
- .fedora-35-tests
needs:
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
- x86_64-fedora-35-prebuilt-env
- project: libvirt/libvirt-perl
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
job: x86_64-fedora-35-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-fedora-35-prebuilt-env
ref: master
artifacts: 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
fedora-35-tests-local-env:
extends:
- .integration_tests_local_env
- .fedora-35-tests
needs:
- x86_64-fedora-35-local-env
- project: libvirt/libvirt-perl
job: x86_64-fedora-35-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-fedora-35-prebuilt-env
ref: master
artifacts: 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
.fedora-36-tests:
variables:
# needed by libvirt-gitlab-executor
DISTRO: fedora-36
# 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
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
fedora-36-tests-prebuilt-env:
extends:
- .integration_tests_prebuilt_env
- .fedora-36-tests
needs:
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
- x86_64-fedora-36-prebuilt-env
- project: libvirt/libvirt-perl
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: 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
fedora-36-tests-local-env:
extends:
- .integration_tests_local_env
- .fedora-36-tests
needs:
- x86_64-fedora-36-local-env
- project: libvirt/libvirt-perl
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: 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
.fedora-36-upstream-qemu-tests:
variables:
# needed by libvirt-gitlab-executor
DISTRO: fedora-36
# 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
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
fedora-36-upstream-qemu-tests-prebuilt-env:
extends:
- .integration_tests_prebuilt_env
- .fedora-36-upstream-qemu-tests
needs:
- x86_64-fedora-36-prebuilt-env
- project: libvirt/libvirt-perl
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: 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
fedora-36-upstream-qemu-tests-local-env:
extends:
- .integration_tests_local_env
- .fedora-36-upstream-qemu-tests
needs:
- x86_64-fedora-36-local-env
- project: libvirt/libvirt-perl
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: true
- project: libvirt/libvirt-python
job: x86_64-fedora-36-prebuilt-env
ref: master
artifacts: true