NetworkManager/.gitlab-ci.yml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

710 lines
18 KiB
YAML
Raw Permalink Normal View History

gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
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 #
# Edit .gitlab-ci/ci.template instead #
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
# #
# Regenerate with:
# TEMPLATE_SHA="$(sed -n 's/^.templates_sha: *\&template_sha *\([0-9a-f]\+\)$/\1/p' ./.gitlab-ci/ci.template)"
# pip3 install "git+http://gitlab.freedesktop.org/freedesktop/ci-templates@$TEMPLATE_SHA"
# ci-fairy generate-template
#
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
########################################
# see https://docs.gitlab.com/ee/ci/yaml/#includefile
.templates_sha: &template_sha 98b1218f146a1ec96d65e3ce0041f9a6ec5cb5e6
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
include:
# Alpine container builder template
- project: 'freedesktop/ci-templates'
ref: *template_sha
file: '/templates/alpine.yml'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
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'
- project: 'freedesktop/ci-templates'
file: '/templates/ci-fairy.yml'
stages:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
- prep
- tier1
- tier2
- tier3
- deploy
- triage
- coverity
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_UPSTREAM_REPO: NetworkManager/NetworkManager
GIT_DEPTH: 1
# These tags should be updated each time the list of packages is updated
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
# changing these will force rebuilding the associated image
# Note: these tags have no meaning and are not tied to a particular NM version
#
# This is done by running `ci-fairy generate-template` and possibly bumping
# ".default_tag".
ALPINE_TAG: 'tag-759073a4a7c5'
CENTOS_TAG: 'tag-0d2843d78314'
DEBIAN_TAG: 'tag-529c288644bc'
FEDORA_TAG: 'tag-0d2843d78314'
UBUNTU_TAG: 'tag-529c288644bc'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +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'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
FEDORA_EXEC: 'bash .gitlab-ci/fedora-install.sh'
UBUNTU_EXEC: 'bash .gitlab-ci/debian-install.sh'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
.nm_artifacts:
variables:
NM_BUILD_TARBALL: 1
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
artifacts:
expire_in: 5 days
when: always
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
paths:
- docs-html
- NetworkManager-1*.tar.xz
- NetworkManager-1*.src.rpm
- nm-test.log
.nm_artifacts_debug:
artifacts:
expire_in: 5 days
when: always
paths:
- nm-test.log
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
#################################################################
# #
# prep stage #
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
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.
tier1:fedora:41@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@fedora
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '41'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
FDO_DISTRIBUTION_EXEC: $FEDORA_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
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
tier2:centos:stream9@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@centos
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: 'stream9'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
FDO_DISTRIBUTION_EXEC: $CENTOS_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier2:ubuntu:devel@prep:
extends:
- .fdo.container-build@ubuntu
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: 'devel'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC: $UBUNTU_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier2:debian:testing@prep:
extends:
- .fdo.container-build@debian
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: 'testing'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC: $DEBIAN_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier2:debian:sid@prep:
extends:
- .fdo.container-build@debian
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: 'sid'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC: $DEBIAN_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier2:alpine:edge@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@alpine
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
stage: prep
variables:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: 'edge'
FDO_DISTRIBUTION_TAG: $ALPINE_TAG
FDO_DISTRIBUTION_EXEC: $ALPINE_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:fedora:40@prep:
extends:
- .fdo.container-build@fedora
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '40'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
FDO_DISTRIBUTION_EXEC: $FEDORA_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
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
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:ubuntu:24.04@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@ubuntu
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '24.04'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC: $UBUNTU_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:ubuntu:22.04@prep:
extends:
- .fdo.container-build@ubuntu
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '22.04'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC: $UBUNTU_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:ubuntu:20.04@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@ubuntu
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '20.04'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC: $UBUNTU_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:debian:12@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@debian
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '12'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC: $DEBIAN_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:alpine:3.20@prep:
extends:
- .fdo.container-build@alpine
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '3.20'
FDO_DISTRIBUTION_TAG: $ALPINE_TAG
FDO_DISTRIBUTION_EXEC: $ALPINE_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:alpine:3.19@prep:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.container-build@alpine
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
stage: prep
variables:
GIT_STRATEGY: none
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
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
tier3:alpine:3.17@prep:
extends:
- .fdo.container-build@alpine
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '3.17'
FDO_DISTRIBUTION_TAG: $ALPINE_TAG
FDO_DISTRIBUTION_EXEC: $ALPINE_EXEC
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
when: manual
allow_failure: true
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
#################################################################
# #
# tierN stage #
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
# #
#################################################################
.build@template:
script:
- env
- r=0
- .gitlab-ci/run-test.sh 2>&1 | tee /tmp/nm-test.log || r=$?
- mv /tmp/nm-test.log .
- exit $r
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
dependencies: []
t_fedora:41:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@fedora
- .nm_artifacts
stage: tier1
parallel:
matrix:
- NM_TEST_SELECT_RUN:
- meson+gcc+docs+valgrind
- meson+clang
- rpm+meson
- tarball+meson
- tarball
- subtree
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: '41'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
needs:
- "tier1:fedora:41@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
t_fedora:rawhide:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@fedora
- .nm_artifacts_debug
stage: tier2
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: 'rawhide'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
needs:
- "tier2:fedora:rawhide@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
t_centos:stream9:
extends:
- .build@template
- .fdo.distribution-image@centos
- .nm_artifacts_debug
stage: tier2
variables:
FDO_DISTRIBUTION_VERSION: 'stream9'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
needs:
- "tier2:centos:stream9@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_ubuntu:devel:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@ubuntu
- .nm_artifacts_debug
stage: tier2
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: 'devel'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
needs:
- "tier2:ubuntu:devel@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
t_debian:testing:
extends:
- .build@template
- .fdo.distribution-image@debian
- .nm_artifacts_debug
stage: tier2
variables:
FDO_DISTRIBUTION_VERSION: 'testing'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
needs:
- "tier2:debian:testing@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_debian:sid:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@debian
- .nm_artifacts_debug
stage: tier2
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: 'sid'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
needs:
- "tier2:debian:sid@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_alpine:edge:
extends:
- .build@template
- .fdo.distribution-image@alpine
- .nm_artifacts_debug
stage: tier2
variables:
FDO_DISTRIBUTION_VERSION: 'edge'
FDO_DISTRIBUTION_TAG: $ALPINE_TAG
needs:
- "tier2:alpine:edge@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
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'
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"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_ubuntu:24.04:
extends:
- .build@template
- .fdo.distribution-image@ubuntu
- .nm_artifacts_debug
stage: tier3
variables:
FDO_DISTRIBUTION_VERSION: '24.04'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
needs:
- "tier3:ubuntu:24.04@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_ubuntu:22.04:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@ubuntu
- .nm_artifacts_debug
stage: tier3
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: '22.04'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
needs:
- "tier3:ubuntu:22.04@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_ubuntu:20.04:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@ubuntu
- .nm_artifacts_debug
stage: tier3
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: '20.04'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
needs:
- "tier3:ubuntu:20.04@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_debian:12:
extends:
- .build@template
- .fdo.distribution-image@debian
- .nm_artifacts_debug
stage: tier3
variables:
FDO_DISTRIBUTION_VERSION: '12'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
needs:
- "tier3:debian:12@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_alpine:3.20:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .build@template
- .fdo.distribution-image@alpine
- .nm_artifacts_debug
stage: tier3
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
variables:
FDO_DISTRIBUTION_VERSION: '3.20'
FDO_DISTRIBUTION_TAG: $ALPINE_TAG
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
needs:
- "tier3:alpine:3.20@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
t_alpine:3.19:
extends:
- .build@template
- .fdo.distribution-image@alpine
- .nm_artifacts_debug
stage: tier3
variables:
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
needs:
- "tier3:alpine:3.18@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
t_alpine:3.17:
extends:
- .build@template
- .fdo.distribution-image@alpine
- .nm_artifacts_debug
stage: tier3
variables:
FDO_DISTRIBUTION_VERSION: '3.17'
FDO_DISTRIBUTION_TAG: $ALPINE_TAG
needs:
- "tier3:alpine:3.17@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
#################################################################
# #
# specific jobs #
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
# #
#################################################################
check-patch:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.distribution-image@fedora
variables:
FDO_DISTRIBUTION_VERSION: '41'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
needs:
- "tier1:fedora:41@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
stage: tier1
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:
- .fdo.distribution-image@fedora
variables:
FDO_DISTRIBUTION_VERSION: '41'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
needs:
- "tier1:fedora:41@prep"
rules:
- if: $CI_PIPELINE_SOURCE != 'schedule'
stage: tier1
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
script:
- date '+%Y%m%d-%H%M%S'; clang-format --version
- date '+%Y%m%d-%H%M%S'; black --version
- date '+%Y%m%d-%H%M%S'; contrib/scripts/nm-python-black-format.sh --check
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
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
- date '+%Y%m%d-%H%M%S'; contrib/scripts/nm-code-format.sh -n
- 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 ]
pages:
stage: deploy
script:
- mv docs-html public
artifacts:
expire_in: 20 days
paths:
- public
rules:
- if: $CI_PIPELINE_SOURCE == 'schedule'
when: never
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == 'main'
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
dependencies:
- "t_fedora:41: [meson+gcc+docs+valgrind]"
needs:
- "t_fedora:41: [meson+gcc+docs+valgrind]"
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
coverity:
extends:
- .fdo.distribution-image@fedora
variables:
FDO_DISTRIBUTION_VERSION: '40'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
stage: coverity
needs: []
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULED_PIPELINE_NAME == "weekly"
script:
- dnf install -y curl
- CC=gcc CONFIGURE_ONLY=1 contrib/scripts/nm-ci-run.sh
- cd build
- ../.gitlab-ci/coverity.sh download
- cov-analysis-linux64-*/bin/cov-build --dir cov-int ninja
- ../.gitlab-ci/coverity.sh upload
# 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:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULED_PIPELINE_NAME == "weekly"
script:
- ci-fairy -v --authfile $AUTHFILE delete-image --project NetworkManager/NetworkManager --all
# 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'
- if: $CI_PIPELINE_SOURCE == 'schedule'
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- if: $CI_COMMIT_BRANCH