2020-10-29 23:19:11 +00:00
# vim: set expandtab shiftwidth=2 tabstop=8 textwidth=0 filetype=yaml:
########################################
# #
# THIS FILE IS GENERATED, DO NOT EDIT #
2022-06-27 08:47:30 +00:00
# Edit .gitlab-ci/ci.template instead #
2020-10-29 23:19:11 +00:00
# #
2022-11-29 07:29:10 +00:00
# Regenerate with:
2023-05-31 14:54:09 +00:00
# TEMPLATE_SHA="$(sed -n 's/^.templates_sha: *\&template_sha *\([0-9a-f]\+\)$/\1/p' ./.gitlab-ci/ci.template)"
2022-11-29 07:29:10 +00:00
# pip3 install "git+http://gitlab.freedesktop.org/freedesktop/ci-templates@$TEMPLATE_SHA"
# ci-fairy generate-template
#
2020-10-29 23:19:11 +00:00
########################################
2023-05-31 14:54:09 +00:00
# see https://docs.gitlab.com/ee/ci/yaml/#includefile
2024-04-19 08:36:13 +00:00
.templates_sha : &template_sha 98b1218f146a1ec96d65e3ce0041f9a6ec5cb5e6
2020-10-29 23:19:11 +00:00
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
2020-10-29 23:19:11 +00:00
include :
2020-12-10 19:08:00 +00:00
# Alpine container builder template
- project : 'freedesktop/ci-templates'
ref : *template_sha
file : '/templates/alpine.yml'
2020-10-29 23:19:11 +00:00
# Centos container builder template
- project : 'freedesktop/ci-templates'
ref : *template_sha
file : '/templates/centos.yml'
# Debian container builder template
- project : 'freedesktop/ci-templates'
ref : *template_sha
file : '/templates/debian.yml'
# Fedora container builder template
- project : 'freedesktop/ci-templates'
ref : *template_sha
file : '/templates/fedora.yml'
# Ubuntu container builder template
- project : 'freedesktop/ci-templates'
ref : *template_sha
file : '/templates/ubuntu.yml'
2024-04-19 08:36:13 +00:00
- project : 'freedesktop/ci-templates'
file : '/templates/ci-fairy.yml'
2018-10-15 11:17:22 +00:00
stages :
2020-10-29 23:19:11 +00:00
- prep
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
- tier1
- tier2
- tier3
2018-10-15 11:17:22 +00:00
- deploy
2020-03-18 15:01:30 +00:00
- triage
2024-06-19 13:13:30 +00:00
- coverity
2020-10-29 23:19:11 +00:00
variables :
FDO_UPSTREAM_REPO : NetworkManager/NetworkManager
GIT_DEPTH : 1
2021-05-04 13:20:10 +00:00
# These tags should be updated each time the list of packages is updated
2020-10-29 23:19:11 +00:00
# changing these will force rebuilding the associated image
2020-11-17 21:57:50 +00:00
# Note: these tags have no meaning and are not tied to a particular NM version
2021-05-04 13:20:10 +00:00
#
2022-06-27 08:47:30 +00:00
# This is done by running `ci-fairy generate-template` and possibly bumping
2021-05-04 13:20:10 +00:00
# ".default_tag".
2024-08-22 12:39:52 +00:00
ALPINE_TAG : 'tag-759073a4a7c5'
CENTOS_TAG : 'tag-0d2843d78314'
DEBIAN_TAG : 'tag-529c288644bc'
FEDORA_TAG : 'tag-0d2843d78314'
UBUNTU_TAG : 'tag-529c288644bc'
2020-10-29 23:19:11 +00:00
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
ALPINE_EXEC : 'bash .gitlab-ci/alpine-install.sh'
CENTOS_EXEC : 'bash .gitlab-ci/fedora-install.sh'
DEBIAN_EXEC : 'bash .gitlab-ci/debian-install.sh'
2020-10-29 23:19:11 +00:00
FEDORA_EXEC : 'bash .gitlab-ci/fedora-install.sh'
2020-11-17 12:25:54 +00:00
UBUNTU_EXEC : 'bash .gitlab-ci/debian-install.sh'
2020-10-29 23:19:11 +00:00
.nm_artifacts :
2020-11-10 17:43:53 +00:00
variables :
NM_BUILD_TARBALL : 1
2020-10-29 23:19:11 +00:00
artifacts :
2022-03-17 12:48:15 +00:00
expire_in : 5 days
when : always
2020-10-29 23:19:11 +00:00
paths :
- docs-html
- NetworkManager-1*.tar.xz
- NetworkManager-1*.src.rpm
2022-03-17 12:48:15 +00:00
- nm-test.log
.nm_artifacts_debug :
artifacts :
expire_in : 5 days
when : always
paths :
- nm-test.log
2018-10-15 11:17:22 +00:00
2020-10-29 23:19:11 +00:00
#################################################################
# #
2023-05-09 07:52:47 +00:00
# prep stage #
2020-10-29 23:19:11 +00:00
# #
#################################################################
# Build a container for each distribution + version. The ci-templates
# will re-use the containers if the tag doesn't change.
2024-08-29 10:13:00 +00:00
tier1:fedora:41@prep :
2020-10-29 23:19:11 +00:00
extends :
- .fdo.container-build@fedora
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '41'
2020-10-29 23:19:11 +00:00
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
FDO_DISTRIBUTION_EXEC : $FEDORA_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2019-05-24 10:48:20 +00:00
2024-08-29 10:13:00 +00:00
tier2:fedora:rawhide@prep :
extends :
- .fdo.container-build@fedora
stage : prep
variables :
GIT_STRATEGY : none
FDO_DISTRIBUTION_VERSION : 'rawhide'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
FDO_DISTRIBUTION_EXEC : $FEDORA_EXEC
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2024-05-29 16:24:51 +00:00
tier2:centos:stream9@prep :
2020-10-29 23:19:11 +00:00
extends :
2024-05-29 16:24:51 +00:00
- .fdo.container-build@centos
2020-10-29 23:19:11 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-05-29 16:24:51 +00:00
FDO_DISTRIBUTION_VERSION : 'stream9'
FDO_DISTRIBUTION_TAG : $CENTOS_TAG
FDO_DISTRIBUTION_EXEC : $CENTOS_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2024-05-29 16:24:51 +00:00
when : manual
allow_failure : true
2024-04-04 10:15:06 +00:00
2024-08-29 10:13:00 +00:00
tier2:ubuntu:devel@prep :
2024-04-04 10:15:06 +00:00
extends :
2024-08-29 10:13:00 +00:00
- .fdo.container-build@ubuntu
2024-04-04 10:15:06 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'devel'
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC : $UBUNTU_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2024-05-29 16:24:51 +00:00
when : manual
allow_failure : true
2024-04-04 10:15:06 +00:00
2024-08-29 10:13:00 +00:00
tier2:debian:testing@prep :
2024-04-04 10:15:06 +00:00
extends :
- .fdo.container-build@debian
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'testing'
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_TAG : $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC : $DEBIAN_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2020-09-25 14:08:59 +00:00
2024-08-29 10:13:00 +00:00
tier2:debian:sid@prep :
2023-11-02 14:45:43 +00:00
extends :
2024-04-04 10:15:06 +00:00
- .fdo.container-build@debian
2023-11-02 14:45:43 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'sid'
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_TAG : $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC : $DEBIAN_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2023-11-02 14:45:43 +00:00
2024-08-29 10:13:00 +00:00
tier2:alpine:edge@prep :
2020-10-29 23:19:11 +00:00
extends :
2024-08-29 10:13:00 +00:00
- .fdo.container-build@alpine
2020-10-29 23:19:11 +00:00
stage : prep
2019-04-19 07:38:12 +00:00
variables :
2020-10-29 23:19:11 +00:00
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'edge'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
FDO_DISTRIBUTION_EXEC : $ALPINE_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2019-01-27 14:30:20 +00:00
2024-08-29 10:13:00 +00:00
tier3:fedora:40@prep :
2022-05-28 16:11:30 +00:00
extends :
2024-08-29 10:13:00 +00:00
- .fdo.container-build@fedora
2022-05-28 16:11:30 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '40'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
FDO_DISTRIBUTION_EXEC : $FEDORA_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2022-05-28 16:11:30 +00:00
2024-04-04 10:15:06 +00:00
tier3:fedora:39@prep :
extends :
- .fdo.container-build@fedora
stage : prep
variables :
GIT_STRATEGY : none
FDO_DISTRIBUTION_VERSION : '39'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
FDO_DISTRIBUTION_EXEC : $FEDORA_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2024-04-04 10:15:06 +00:00
2024-08-29 10:13:00 +00:00
tier3:ubuntu:24.04@prep :
2020-10-29 23:19:11 +00:00
extends :
- .fdo.container-build@ubuntu
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '24.04'
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC : $UBUNTU_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2020-11-09 09:48:05 +00:00
2024-04-04 10:15:06 +00:00
tier3:ubuntu:22.04@prep :
2020-11-09 09:48:05 +00:00
extends :
- .fdo.container-build@ubuntu
stage : prep
variables :
GIT_STRATEGY : none
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_VERSION : '22.04'
2020-10-29 23:19:11 +00:00
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC : $UBUNTU_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2019-09-25 09:28:19 +00:00
2024-08-29 10:13:00 +00:00
tier3:ubuntu:20.04@prep :
2020-10-29 23:19:11 +00:00
extends :
2024-04-04 10:15:06 +00:00
- .fdo.container-build@ubuntu
2020-10-29 23:19:11 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '20.04'
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC : $UBUNTU_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2019-04-18 06:46:53 +00:00
2024-08-29 10:13:00 +00:00
tier3:debian:12@prep :
2020-10-29 23:19:11 +00:00
extends :
2024-08-29 10:13:00 +00:00
- .fdo.container-build@debian
2020-10-29 23:19:11 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '12'
FDO_DISTRIBUTION_TAG : $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC : $DEBIAN_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2019-05-24 10:48:20 +00:00
2024-08-29 10:13:00 +00:00
tier3:alpine:3.20@prep :
2021-08-30 08:22:52 +00:00
extends :
2024-08-29 10:13:00 +00:00
- .fdo.container-build@alpine
2021-08-30 08:22:52 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '3.20'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
FDO_DISTRIBUTION_EXEC : $ALPINE_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2021-08-30 08:22:52 +00:00
2024-08-29 10:13:00 +00:00
tier3:alpine:3.19@prep :
2020-10-29 23:19:11 +00:00
extends :
2024-08-29 10:13:00 +00:00
- .fdo.container-build@alpine
2020-10-29 23:19:11 +00:00
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '3.19'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
FDO_DISTRIBUTION_EXEC : $ALPINE_EXEC
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
tier3:alpine:3.18@prep :
extends :
- .fdo.container-build@alpine
stage : prep
variables :
GIT_STRATEGY : none
FDO_DISTRIBUTION_VERSION : '3.18'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
FDO_DISTRIBUTION_EXEC : $ALPINE_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2020-05-13 20:56:33 +00:00
2024-08-29 10:13:00 +00:00
tier3:alpine:3.17@prep :
2020-12-10 19:08:00 +00:00
extends :
- .fdo.container-build@alpine
stage : prep
variables :
GIT_STRATEGY : none
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '3.17'
2020-12-10 19:08:00 +00:00
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
FDO_DISTRIBUTION_EXEC : $ALPINE_EXEC
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
when : manual
allow_failure : true
2020-12-10 19:08:00 +00:00
2020-10-29 23:19:11 +00:00
#################################################################
# #
2023-05-09 07:52:47 +00:00
# tierN stage #
2020-10-29 23:19:11 +00:00
# #
#################################################################
.build@template :
script :
2022-03-17 20:25:44 +00:00
- env
2022-03-30 09:02:56 +00:00
- r=0
- .gitlab-ci/run-test.sh 2>&1 | tee /tmp/nm-test.log || r=$?
2022-03-17 12:48:15 +00:00
- mv /tmp/nm-test.log .
2022-03-30 09:02:56 +00:00
- exit $r
2020-10-29 23:19:11 +00:00
dependencies : [ ]
2022-03-17 12:48:15 +00:00
2024-08-29 10:13:00 +00:00
t_fedora:41 :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
- .fdo.distribution-image@fedora
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
- .nm_artifacts
stage : tier1
gitlab-ci: use parallel:matrix for tier1 tests
The benefit is that instead of one long running job for fedora:37 (the
current tier1 test), we have several smaller.
A minor downside is, that if the build is broken, then usually the very
first test would already fail. Previously, that meant that the follow up
tests were skipped. Now, they run all in parallel. However, test
failures should be the exception, so the wasted resources are probably
irrelevant. The upside is, that we can see which tests fail, and we run
them much faster (in parallel).
This is only done for the tier1 test, because those tests are started
automatically. Other tiers need to be triggered manually, which already
means a lot of clicking. Making those also matrix tests, would result in
an insane amount of clicking. As those other tests are run much more
seldom, having them huge is probably fine.
2023-04-12 15:01:19 +00:00
parallel :
matrix :
- NM_TEST_SELECT_RUN :
- meson+gcc+docs+valgrind
- meson+clang
- rpm+meson
2024-02-05 12:59:50 +00:00
- tarball+meson
gitlab-ci: use parallel:matrix for tier1 tests
The benefit is that instead of one long running job for fedora:37 (the
current tier1 test), we have several smaller.
A minor downside is, that if the build is broken, then usually the very
first test would already fail. Previously, that meant that the follow up
tests were skipped. Now, they run all in parallel. However, test
failures should be the exception, so the wasted resources are probably
irrelevant. The upside is, that we can see which tests fail, and we run
them much faster (in parallel).
This is only done for the tier1 test, because those tests are started
automatically. Other tiers need to be triggered manually, which already
means a lot of clicking. Making those also matrix tests, would result in
an insane amount of clicking. As those other tests are run much more
seldom, having them huge is probably fine.
2023-04-12 15:01:19 +00:00
- tarball
- subtree
2020-10-29 23:19:11 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '41'
2020-10-29 23:19:11 +00:00
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
needs :
2024-08-29 10:13:00 +00:00
- "tier1:fedora:41@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2020-10-29 23:19:11 +00:00
2024-08-29 10:13:00 +00:00
t_fedora:rawhide :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@fedora
2024-05-29 16:24:51 +00:00
- .nm_artifacts_debug
stage : tier2
2020-10-29 23:19:11 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'rawhide'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
2020-10-29 23:19:11 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier2:fedora:rawhide@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2020-10-29 23:19:11 +00:00
2024-08-29 10:13:00 +00:00
t_centos:stream9 :
2023-11-02 14:45:43 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@centos
2023-11-02 14:45:43 +00:00
- .nm_artifacts_debug
2024-05-29 16:24:51 +00:00
stage : tier2
2023-11-02 14:45:43 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'stream9'
FDO_DISTRIBUTION_TAG : $CENTOS_TAG
2023-11-02 14:45:43 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier2:centos:stream9@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2023-11-02 14:45:43 +00:00
2024-08-29 10:13:00 +00:00
t_ubuntu:devel :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@ubuntu
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier2
2020-10-29 23:19:11 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'devel'
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
2020-10-29 23:19:11 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier2:ubuntu:devel@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2020-10-29 23:19:11 +00:00
2024-04-04 10:15:06 +00:00
t_debian:testing :
2022-05-28 16:11:30 +00:00
extends :
- .build@template
2024-04-04 10:15:06 +00:00
- .fdo.distribution-image@debian
2022-05-28 16:11:30 +00:00
- .nm_artifacts_debug
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier2
2022-05-28 16:11:30 +00:00
variables :
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_VERSION : 'testing'
FDO_DISTRIBUTION_TAG : $DEBIAN_TAG
2022-05-28 16:11:30 +00:00
needs :
2024-04-04 10:15:06 +00:00
- "tier2:debian:testing@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2022-05-28 16:11:30 +00:00
2024-08-29 10:13:00 +00:00
t_debian:sid :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@debian
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier2
2020-10-29 23:19:11 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : 'sid'
FDO_DISTRIBUTION_TAG : $DEBIAN_TAG
2020-10-29 23:19:11 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier2:debian:sid@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2020-11-09 09:48:05 +00:00
2024-04-04 10:15:06 +00:00
t_alpine:edge :
2020-11-09 09:48:05 +00:00
extends :
- .build@template
2024-04-04 10:15:06 +00:00
- .fdo.distribution-image@alpine
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier2
2020-11-09 09:48:05 +00:00
variables :
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_VERSION : 'edge'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
needs :
- "tier2:alpine:edge@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2024-04-04 10:15:06 +00:00
2024-08-29 10:13:00 +00:00
t_fedora:40 :
extends :
- .build@template
- .fdo.distribution-image@fedora
- .nm_artifacts_debug
stage : tier3
variables :
FDO_DISTRIBUTION_VERSION : '40'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
needs :
- "tier3:fedora:40@prep"
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2024-04-04 10:15:06 +00:00
t_fedora:39 :
extends :
- .build@template
- .fdo.distribution-image@fedora
- .nm_artifacts_debug
stage : tier3
variables :
FDO_DISTRIBUTION_VERSION : '39'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
needs :
- "tier3:fedora:39@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2024-04-04 10:15:06 +00:00
2024-08-29 10:13:00 +00:00
t_ubuntu:24.04 :
2024-04-04 10:15:06 +00:00
extends :
- .build@template
- .fdo.distribution-image@ubuntu
- .nm_artifacts_debug
stage : tier3
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '24.04'
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
needs :
2024-08-29 10:13:00 +00:00
- "tier3:ubuntu:24.04@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2019-07-11 09:53:37 +00:00
2024-04-04 10:15:06 +00:00
t_ubuntu:22.04 :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
2024-04-04 10:15:06 +00:00
- .fdo.distribution-image@ubuntu
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
2024-04-04 10:15:06 +00:00
stage : tier3
2020-10-29 23:19:11 +00:00
variables :
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_VERSION : '22.04'
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
2020-10-29 23:19:11 +00:00
needs :
2024-04-04 10:15:06 +00:00
- "tier3:ubuntu:22.04@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2019-04-18 06:46:53 +00:00
2024-08-29 10:13:00 +00:00
t_ubuntu:20.04 :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
2024-04-04 10:15:06 +00:00
- .fdo.distribution-image@ubuntu
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
2024-04-04 10:15:06 +00:00
stage : tier3
2020-10-29 23:19:11 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '20.04'
2024-04-04 10:15:06 +00:00
FDO_DISTRIBUTION_TAG : $UBUNTU_TAG
2020-10-29 23:19:11 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier3:ubuntu:20.04@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2019-07-10 10:29:48 +00:00
2024-08-29 10:13:00 +00:00
t_debian:12 :
2021-08-30 08:22:52 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@debian
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
2024-04-04 10:15:06 +00:00
stage : tier3
2021-08-30 08:22:52 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '12'
FDO_DISTRIBUTION_TAG : $DEBIAN_TAG
2021-08-30 08:22:52 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier3:debian:12@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2021-08-30 08:22:52 +00:00
2024-08-29 10:13:00 +00:00
t_alpine:3.20 :
2020-10-29 23:19:11 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@alpine
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier3
2020-10-29 23:19:11 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '3.20'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
2020-10-29 23:19:11 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier3:alpine:3.20@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2020-10-29 23:19:11 +00:00
2024-08-29 10:13:00 +00:00
t_alpine:3.19 :
2023-05-22 11:54:57 +00:00
extends :
- .build@template
2024-08-29 10:13:00 +00:00
- .fdo.distribution-image@alpine
2023-05-22 11:54:57 +00:00
- .nm_artifacts_debug
2024-04-04 10:15:06 +00:00
stage : tier3
2023-05-22 11:54:57 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '3.19'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
needs :
- "tier3:alpine:3.19@prep"
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
t_alpine:3.18 :
extends :
- .build@template
- .fdo.distribution-image@alpine
- .nm_artifacts_debug
stage : tier3
variables :
FDO_DISTRIBUTION_VERSION : '3.18'
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
2023-05-22 11:54:57 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "tier3:alpine:3.18@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2023-05-22 11:54:57 +00:00
2024-08-29 10:13:00 +00:00
t_alpine:3.17 :
2020-12-10 19:08:00 +00:00
extends :
- .build@template
- .fdo.distribution-image@alpine
2022-03-17 12:48:15 +00:00
- .nm_artifacts_debug
2024-04-04 10:15:06 +00:00
stage : tier3
2020-12-10 19:08:00 +00:00
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '3.17'
2020-12-10 19:08:00 +00:00
FDO_DISTRIBUTION_TAG : $ALPINE_TAG
needs :
2024-08-29 10:13:00 +00:00
- "tier3:alpine:3.17@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
2020-12-10 19:08:00 +00:00
2020-10-29 23:19:11 +00:00
#################################################################
# #
2023-05-09 07:52:47 +00:00
# specific jobs #
2020-10-29 23:19:11 +00:00
# #
#################################################################
2020-11-10 09:47:04 +00:00
check-patch :
2020-10-29 23:19:11 +00:00
extends :
2022-03-17 19:50:54 +00:00
- .fdo.distribution-image@fedora
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '41'
2022-03-17 19:50:54 +00:00
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
needs :
2024-08-29 10:13:00 +00:00
- "tier1:fedora:41@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier1
2020-11-10 09:47:04 +00:00
script :
- date '+%Y%m%d-%H%M%S'; NM_CHECKPATCH_FETCH_UPSTREAM=1 contrib/scripts/checkpatch-feature-branch.sh
allow_failure : true
check-tree :
extends :
2022-03-17 19:50:54 +00:00
- .fdo.distribution-image@fedora
variables :
2024-08-29 10:13:00 +00:00
FDO_DISTRIBUTION_VERSION : '41'
2022-03-17 19:50:54 +00:00
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
needs :
2024-08-29 10:13:00 +00:00
- "tier1:fedora:41@prep"
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE != 'schedule'
gitlab-ci: add multiple stages/tiers for tests
We have many test configurations (i.e. distros like fedora:37,
debian:9). Almost all of them run manually triggered, because running
them every time would be wasteful.
Still, even as we trigger those tests only seldom, whenever we trigger
them all together, they consume still too many resources of the
freedesktop.org gitlab infrastructure.
One possibility would be to just drop old distros (e.g. fedora:30).
Which tests are setup in gitlab-ci is constantly refined and adjusted.
So dropping some distros is not necessarily wrong and bound to happen
eventually.
However, I also don't find it great to just disable tests that are still
passing. If we want to avoid consuming too many resources, we can just
choose not to run those tests. We don't need to enforce that by deleting
tests. Once deleted, such a configuration cannot be tested anymore as it
would be too cumbersome to recreate the setup manually.
Instead, introduce stages/tiers to clearer mark configuration that we
should test even less frequently.
Note that it is still required from the developer to not trigger too
many tests at once, to not monopolize the CI resources. The stages
should make that clearer to see, but don't solve it. Deleting tests
might solve it, but only if we delete a significant number of those
tests, which seems not desirable.
2023-04-11 10:23:30 +00:00
stage : tier1
2020-10-29 23:19:11 +00:00
script :
2023-06-01 06:49:07 +00:00
- date '+%Y%m%d-%H%M%S'; clang-format --version
- date '+%Y%m%d-%H%M%S'; black --version
2022-04-01 11:50:19 +00:00
- date '+%Y%m%d-%H%M%S'; contrib/scripts/nm-python-black-format.sh --check
2020-10-29 23:19:11 +00:00
- date '+%Y%m%d-%H%M%S'; git ls-files -z -- 'po/*.po' | xargs -0 -n1 msgfmt -vc
2021-09-16 06:46:17 +00:00
- date '+%Y%m%d-%H%M%S'; contrib/scripts/nm-code-format.sh -n
2020-11-10 09:47:04 +00:00
- date '+%Y%m%d-%H%M%S'; ci-fairy generate-template && git diff --exit-code
2024-08-22 11:12:29 +00:00
- date '+%Y%m%d-%H%M%S'; meson setup build && [ "$(LANG=C ninja -C build NetworkManager-update-po 2>&1 1>/dev/null | grep -c 'warning:')" = 0 ]
2019-01-27 14:30:20 +00:00
2018-10-15 11:17:22 +00:00
pages :
stage : deploy
script :
- mv docs-html public
artifacts :
expire_in : 20 days
paths :
- public
2024-04-19 08:36:13 +00:00
rules :
- if : $CI_PIPELINE_SOURCE == 'schedule'
when : never
- if : $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == 'main'
2020-10-29 23:19:11 +00:00
dependencies :
2024-08-29 10:13:00 +00:00
- "t_fedora:41: [meson+gcc+docs+valgrind]"
2020-11-11 07:46:52 +00:00
needs :
2024-08-29 10:13:00 +00:00
- "t_fedora:41: [meson+gcc+docs+valgrind]"
2020-03-18 15:01:30 +00:00
2024-05-23 09:55:52 +00:00
triage:issues :
stage : triage
image : ruby:3
rules :
- if : $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULED_PIPELINE_NAME == "daily"
tags :
- placeholder-job # The job mostly waits on network requests, so use only one CPU : https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/1358#note_2457416
script :
- gem install gitlab-triage
- gitlab-triage --debug --token $API_TOKEN --source-id $CI_PROJECT_ID
2023-04-13 13:03:16 +00:00
2024-06-19 13:13:30 +00:00
coverity :
extends :
- .fdo.distribution-image@fedora
variables :
FDO_DISTRIBUTION_VERSION : '40'
FDO_DISTRIBUTION_TAG : $FEDORA_TAG
stage : coverity
needs : [ ]
rules :
2024-06-27 11:23:15 +00:00
- if : $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULED_PIPELINE_NAME == "weekly"
2024-06-19 13:13:30 +00:00
script :
- dnf install -y curl
2024-08-22 11:14:01 +00:00
- CC=gcc CONFIGURE_ONLY=1 contrib/scripts/nm-ci-run.sh
2024-06-19 13:13:30 +00:00
- cd build
- ../.gitlab-ci/coverity.sh download
- cov-analysis-linux64-*/bin/cov-build --dir cov-int ninja
- ../.gitlab-ci/coverity.sh upload
2024-04-19 08:36:13 +00:00
# Clean the generated images periodically to get updated snapshots of the distribution images.
# Create an scheduled pipeline to run it, passing an AUTHFILE environment variable of type
# 'File' with an authentication token with API access level.
clean-images :
extends :
- .fdo.ci-fairy
stage : prep
rules :
2024-05-23 09:55:52 +00:00
- if : $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULED_PIPELINE_NAME == "weekly"
2024-04-19 08:36:13 +00:00
script :
- ci-fairy -v --authfile $AUTHFILE delete-image --project NetworkManager/NetworkManager --all
2023-04-13 13:03:16 +00:00
# Have detached MR pipeline (https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html)
# https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540#what-it-means-for-me-a-maintainer-of-a-project-part-of-gitlabfreedesktoporg
workflow :
rules :
- if : $CI_PIPELINE_SOURCE == 'merge_request_event'
2024-05-23 09:55:52 +00:00
- if : $CI_PIPELINE_SOURCE == 'schedule'
2024-05-29 13:02:13 +00:00
- if : $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when : never
- if : $CI_COMMIT_BRANCH