libvirt/ci/gitlab/builds.yml

877 lines
19 KiB
YAML
Raw Normal View History

# THIS FILE WAS AUTO-GENERATED
#
# $ lcitool manifest ci/manifest.yml
#
# https://gitlab.com/libvirt/libvirt-ci
# Native build jobs
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-almalinux-8-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-almalinux-8-container
optional: true
allow_failure: false
variables:
JOB_OPTIONAL: 1
NAME: almalinux-8
RPM: skip
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-almalinux-8-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: docker.io/library/almalinux:8
JOB_OPTIONAL: 1
NAME: almalinux-8
RPM: skip
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-almalinux-8-clang-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-almalinux-8-container
optional: true
allow_failure: false
variables:
CC: clang
NAME: almalinux-8
RPM: skip
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-almalinux-8-clang-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
CC: clang
IMAGE: docker.io/library/almalinux:8
NAME: almalinux-8
RPM: skip
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-alpine-315-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-alpine-315-container
optional: true
allow_failure: false
variables:
NAME: alpine-315
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-alpine-315-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: docker.io/library/alpine:3.15
NAME: alpine-315
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-alpine-edge-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-alpine-edge-container
optional: true
allow_failure: true
variables:
NAME: alpine-edge
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-alpine-edge-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: true
variables:
IMAGE: docker.io/library/alpine:edge
NAME: alpine-edge
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:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-centos-stream-8-container
optional: true
allow_failure: false
variables:
NAME: centos-stream-8
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
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-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: quay.io/centos/centos:stream8
NAME: centos-stream-8
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
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:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-centos-stream-9-container
optional: true
allow_failure: false
variables:
NAME: centos-stream-9
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
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-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: quay.io/centos/centos:stream9
NAME: centos-stream-9
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
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-debian-11-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-debian-11-container
optional: true
allow_failure: false
variables:
NAME: debian-11
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-debian-11-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: docker.io/library/debian:11-slim
NAME: debian-11
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-debian-11-clang-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-debian-11-container
optional: true
allow_failure: false
variables:
NAME: debian-11
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-debian-11-clang-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: docker.io/library/debian:11-slim
NAME: debian-11
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-debian-sid-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-debian-sid-container
optional: true
allow_failure: true
variables:
NAME: debian-sid
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-debian-sid-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: true
variables:
IMAGE: docker.io/library/debian:sid-slim
NAME: debian-sid
x86_64-fedora-36-prebuilt-env:
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
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-fedora-36-container
optional: true
allow_failure: false
variables:
NAME: fedora-36
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
x86_64-fedora-36-local-env:
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
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: registry.fedoraproject.org/fedora:36
NAME: fedora-36
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
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
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-37-prebuilt-env:
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
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-fedora-37-container
optional: true
allow_failure: false
variables:
NAME: fedora-37
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
x86_64-fedora-37-local-env:
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
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: registry.fedoraproject.org/fedora:37
NAME: fedora-37
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
artifacts:
expire_in: 1 day
paths:
- libvirt-rpms
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-rawhide-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-fedora-rawhide-container
optional: true
allow_failure: true
variables:
NAME: fedora-rawhide
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-rawhide-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: true
variables:
IMAGE: registry.fedoraproject.org/fedora:rawhide
NAME: fedora-rawhide
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-rawhide-clang-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-fedora-rawhide-container
optional: true
allow_failure: true
variables:
CC: clang
NAME: fedora-rawhide
RPM: skip
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-rawhide-clang-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: true
variables:
CC: clang
IMAGE: registry.fedoraproject.org/fedora:rawhide
NAME: fedora-rawhide
RPM: skip
x86_64-opensuse-leap-154-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-opensuse-leap-154-container
optional: true
allow_failure: false
variables:
NAME: opensuse-leap-154
RPM: skip
x86_64-opensuse-leap-154-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: registry.opensuse.org/opensuse/leap:15.4
NAME: opensuse-leap-154
RPM: skip
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-opensuse-tumbleweed-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-opensuse-tumbleweed-container
optional: true
allow_failure: true
variables:
NAME: opensuse-tumbleweed
RPM: skip
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-opensuse-tumbleweed-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: true
variables:
IMAGE: registry.opensuse.org/opensuse/tumbleweed:latest
NAME: opensuse-tumbleweed
RPM: skip
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-ubuntu-2004-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-ubuntu-2004-container
optional: true
allow_failure: false
variables:
ASAN_OPTIONS: verify_asan_link_order=0
MESON_ARGS: -Db_lundef=false -Db_sanitize=address,undefined
NAME: ubuntu-2004
UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1
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-ubuntu-2004-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
ASAN_OPTIONS: verify_asan_link_order=0
IMAGE: docker.io/library/ubuntu:20.04
MESON_ARGS: -Db_lundef=false -Db_sanitize=address,undefined
NAME: ubuntu-2004
UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1
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-ubuntu-2204-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-ubuntu-2204-container
optional: true
allow_failure: false
variables:
JOB_OPTIONAL: 1
NAME: ubuntu-2204
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-ubuntu-2204-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
IMAGE: docker.io/library/ubuntu:22.04
JOB_OPTIONAL: 1
NAME: ubuntu-2204
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-ubuntu-2204-clang-prebuilt-env:
extends: .native_build_job_prebuilt_env
needs:
- job: x86_64-ubuntu-2204-container
optional: true
allow_failure: false
variables:
CC: clang
MESON_ARGS: -Db_lundef=false -Db_sanitize=address,undefined
NAME: ubuntu-2204
UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1
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-ubuntu-2204-clang-local-env:
extends: .native_build_job_local_env
needs: []
allow_failure: false
variables:
CC: clang
IMAGE: docker.io/library/ubuntu:22.04
MESON_ARGS: -Db_lundef=false -Db_sanitize=address,undefined
NAME: ubuntu-2204
UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1
# Cross build jobs
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
aarch64-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: aarch64-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: aarch64
JOB_OPTIONAL: 1
NAME: debian-11
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
aarch64-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: aarch64
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
armv6l-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: armv6l-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: armv6l
JOB_OPTIONAL: 1
NAME: debian-11
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
armv6l-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: armv6l
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
armv7l-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: armv7l-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: armv7l
NAME: debian-11
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
armv7l-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: armv7l
IMAGE: docker.io/library/debian:11-slim
NAME: debian-11
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
i686-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: i686-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: i686
JOB_OPTIONAL: 1
NAME: debian-11
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
i686-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: i686
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
mips64el-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: mips64el-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: mips64el
JOB_OPTIONAL: 1
NAME: debian-11
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
mips64el-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: mips64el
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
mipsel-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: mipsel-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: mipsel
JOB_OPTIONAL: 1
NAME: debian-11
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
mipsel-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: mipsel
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
ppc64le-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: ppc64le-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: ppc64le
JOB_OPTIONAL: 1
NAME: debian-11
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
ppc64le-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: ppc64le
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
s390x-debian-11-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: s390x-debian-11-container
optional: true
allow_failure: false
variables:
CROSS: s390x
JOB_OPTIONAL: 1
NAME: debian-11
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
s390x-debian-11-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: s390x
IMAGE: docker.io/library/debian:11-slim
JOB_OPTIONAL: 1
NAME: debian-11
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
aarch64-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: aarch64-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: aarch64
JOB_OPTIONAL: 1
NAME: debian-sid
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
aarch64-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: aarch64
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
armv6l-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: armv6l-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: armv6l
JOB_OPTIONAL: 1
NAME: debian-sid
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
armv6l-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: armv6l
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
armv7l-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: armv7l-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: armv7l
JOB_OPTIONAL: 1
NAME: debian-sid
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
armv7l-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: armv7l
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
i686-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: i686-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: i686
JOB_OPTIONAL: 1
NAME: debian-sid
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
i686-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: i686
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
mips64el-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: mips64el-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: mips64el
JOB_OPTIONAL: 1
NAME: debian-sid
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
mips64el-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: mips64el
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
mipsel-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: mipsel-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: mipsel
JOB_OPTIONAL: 1
NAME: debian-sid
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
mipsel-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: mipsel
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
ppc64le-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: ppc64le-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: ppc64le
JOB_OPTIONAL: 1
NAME: debian-sid
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
ppc64le-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: ppc64le
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
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
s390x-debian-sid-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: s390x-debian-sid-container
optional: true
allow_failure: false
variables:
CROSS: s390x
JOB_OPTIONAL: 1
NAME: debian-sid
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
s390x-debian-sid-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: s390x
IMAGE: docker.io/library/debian:sid-slim
JOB_OPTIONAL: 1
NAME: debian-sid
mingw32-fedora-37-prebuilt-env:
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
extends: .cross_build_job_prebuilt_env
needs:
- job: mingw32-fedora-37-container
optional: true
allow_failure: false
variables:
CROSS: mingw32
JOB_OPTIONAL: 1
NAME: fedora-37
mingw32-fedora-37-local-env:
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
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: mingw32
IMAGE: registry.fedoraproject.org/fedora:37
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_OPTIONAL: 1
NAME: fedora-37
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
mingw64-fedora-37-prebuilt-env:
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
extends: .cross_build_job_prebuilt_env
needs:
- job: mingw64-fedora-37-container
optional: true
allow_failure: false
variables:
CROSS: mingw64
NAME: fedora-37
mingw64-fedora-37-local-env:
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
extends: .cross_build_job_local_env
needs: []
allow_failure: false
variables:
CROSS: mingw64
IMAGE: registry.fedoraproject.org/fedora:37
NAME: fedora-37
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
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
mingw32-fedora-rawhide-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: mingw32-fedora-rawhide-container
optional: true
allow_failure: true
variables:
CROSS: mingw32
NAME: fedora-rawhide
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
mingw32-fedora-rawhide-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: true
variables:
CROSS: mingw32
IMAGE: registry.fedoraproject.org/fedora:rawhide
NAME: fedora-rawhide
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
mingw64-fedora-rawhide-prebuilt-env:
extends: .cross_build_job_prebuilt_env
needs:
- job: mingw64-fedora-rawhide-container
optional: true
allow_failure: true
variables:
CROSS: mingw64
JOB_OPTIONAL: 1
NAME: fedora-rawhide
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
mingw64-fedora-rawhide-local-env:
extends: .cross_build_job_local_env
needs: []
allow_failure: true
variables:
CROSS: mingw64
IMAGE: registry.fedoraproject.org/fedora:rawhide
JOB_OPTIONAL: 1
NAME: fedora-rawhide
# Native cirrus build jobs
x86_64-freebsd-12:
extends: .cirrus_build_job
needs: []
allow_failure: false
variables:
CIRRUS_VM_IMAGE_NAME: freebsd-12-4
CIRRUS_VM_IMAGE_SELECTOR: image_family
CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
INSTALL_COMMAND: pkg install -y
NAME: freebsd-12
UPDATE_COMMAND: pkg update
UPGRADE_COMMAND: pkg upgrade -y
x86_64-freebsd-13:
extends: .cirrus_build_job
needs: []
allow_failure: false
variables:
CIRRUS_VM_IMAGE_NAME: freebsd-13-1
CIRRUS_VM_IMAGE_SELECTOR: image_family
CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
INSTALL_COMMAND: pkg install -y
NAME: freebsd-13
UPDATE_COMMAND: pkg update
UPGRADE_COMMAND: pkg upgrade -y
aarch64-macos-12:
extends: .cirrus_build_job
needs: []
allow_failure: false
variables:
CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-monterey-base:latest
CIRRUS_VM_IMAGE_SELECTOR: image
CIRRUS_VM_INSTANCE_TYPE: macos_instance
INSTALL_COMMAND: brew install
NAME: macos-12
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
UPDATE_COMMAND: brew update
UPGRADE_COMMAND: brew upgrade