system/NetworkManager
system/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager synced 2024-07-21 10:14:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
NetworkManager/.gitlab-ci.yml

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

811 lines
21 KiB
YAML
Raw 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 #
# #
########################################
gitlab-ci: automatically hash build scripts into tag for ci-templates container ci-templates builds and caches the test containers. When the build scripts, the ci-template or "config.yml" changes, we need to bump the tag so that the containers get rebuild. Partly automate this. The tag now gets generated by the template and contains a checksum of certain build files. Thus, if you change any build files, then `ci-fairy generate-template` would generate a different tag. You can not miss that, because we have tests that ensure that our ".gitlab-ci.yml" is up to date. Also, you no longer need to manually bump the tag when a build script changes, just regenerate ".gitlab-ci.yml" with `ci-fairy generate-template`. See also: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/merge_requests/54
2020-11-17 08:21:12 +00:00
.templates_sha: &template_sha 766e3d77c647e404b349e398427e8965a1769b64 # see https://docs.gitlab.com/ee/ci/yaml/#includefile
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:
# 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'
gitlab: add .gitlab-ci.yml for gitlab CI See-also: https://docs.gitlab.com/ee/ci/yaml/
2018-10-15 11:17:22 +00:00
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
gitlab: add .gitlab-ci.yml for gitlab CI See-also: https://docs.gitlab.com/ee/ci/yaml/
2018-10-15 11:17:22 +00:00
- test
- deploy
gitlab-ci: add scheduled pipeline to triage inactive issues and MRs
2020-03-18 15:01:30 +00:00
- triage
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
- container_clean
variables:
FDO_UPSTREAM_REPO: NetworkManager/NetworkManager
GIT_DEPTH: 1
# these tags should be updated each time the list of packages is updated
# changing these will force rebuilding the associated image
# Note: these tags have no meaning and are not tied to a particular
# libinput version
gitlab-ci: combine ubuntu/centos install scripts with their debian/fedora counterparts Ubuntu/Debian and CentOS/Fedora are sufficiently similar that it's better that we have only one variant of ".gitlab-ci/*-install.sh" and "contrib/*/REQUIRED_PACKAGES". This was already the case, however, we used to symlink ".gitlab-ci/centos-install.sh" to "fedora-install.sh". That worked, but it didn't scale very well. For example, if we would follow that pattern, we would also need a symlink "contrib/centos/REQUIRED_PACKAGES" Or should "contrib/centos" symlink to "contrib/fedora"? That seems even more wrong. We already had the "distro.base_type" variable for that. Make use of that also for the install script.
2020-11-17 12:25:54 +00:00
FEDORA_TAG: '2020-11-17.0-b6f225d87807'
UBUNTU_TAG: '2020-11-17.0-e2797fbbfc3a'
DEBIAN_TAG: '2020-11-17.0-e2797fbbfc3a'
CENTOS_TAG: '2020-11-17.0-b6f225d87807'
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'
gitlab-ci: combine ubuntu/centos install scripts with their debian/fedora counterparts Ubuntu/Debian and CentOS/Fedora are sufficiently similar that it's better that we have only one variant of ".gitlab-ci/*-install.sh" and "contrib/*/REQUIRED_PACKAGES". This was already the case, however, we used to symlink ".gitlab-ci/centos-install.sh" to "fedora-install.sh". That worked, but it didn't scale very well. For example, if we would follow that pattern, we would also need a symlink "contrib/centos/REQUIRED_PACKAGES" Or should "contrib/centos" symlink to "contrib/fedora"? That seems even more wrong. We already had the "distro.base_type" variable for that. Make use of that also for the install script.
2020-11-17 12:25:54 +00:00
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
DEBIAN_EXEC: 'bash .gitlab-ci/debian-install.sh'
gitlab-ci: combine ubuntu/centos install scripts with their debian/fedora counterparts Ubuntu/Debian and CentOS/Fedora are sufficiently similar that it's better that we have only one variant of ".gitlab-ci/*-install.sh" and "contrib/*/REQUIRED_PACKAGES". This was already the case, however, we used to symlink ".gitlab-ci/centos-install.sh" to "fedora-install.sh". That worked, but it didn't scale very well. For example, if we would follow that pattern, we would also need a symlink "contrib/centos/REQUIRED_PACKAGES" Or should "contrib/centos" symlink to "contrib/fedora"? That seems even more wrong. We already had the "distro.base_type" variable for that. Make use of that also for the install script.
2020-11-17 12:25:54 +00:00
CENTOS_EXEC: 'bash .gitlab-ci/fedora-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:
gitlab-ci: fix building artifacts (pages) during gitlab-ci test
2020-11-10 17:43:53 +00:00
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: 2 days
paths:
- docs-html
- NetworkManager-1*.tar.xz
- NetworkManager-1*.src.rpm
gitlab: add .gitlab-ci.yml for gitlab CI See-also: https://docs.gitlab.com/ee/ci/yaml/
2018-10-15 11:17:22 +00:00
gitlab-ci: merge "check-ci-script" test with static checks Certain parts of the code are entirely generated or must follow a certain format that can be enforced by a tool. These invariants must never fail: - ci-fairy generate-template (check-ci-script) - black python formatting - clang-format C formatting - msgfmt -vs On the other hand, we also have a checkpatch script that checks the current patch for common errors. These are heuristics and only depend on the current patch (contrary to the previous type that depend on the entire source tree). Refactor the gitlab-ci tests: - split "checkpatch" into "check-patch" and "check-tree". - merge the "check-ci-script" test into "check-tree".
2020-11-10 09:47:04 +00:00
.nm_artifacts_undo:
gitlab-ci: fix building artifacts (pages) during gitlab-ci test
2020-11-10 17:43:53 +00:00
variables:
NM_BUILD_TARBALL: 0
gitlab-ci: merge "check-ci-script" test with static checks Certain parts of the code are entirely generated or must follow a certain format that can be enforced by a tool. These invariants must never fail: - ci-fairy generate-template (check-ci-script) - black python formatting - clang-format C formatting - msgfmt -vs On the other hand, we also have a checkpatch script that checks the current patch for common errors. These are heuristics and only depend on the current patch (contrary to the previous type that depend on the entire source tree). Refactor the gitlab-ci tests: - split "checkpatch" into "check-patch" and "check-tree". - merge the "check-ci-script" test into "check-tree".
2020-11-10 09:47:04 +00:00
artifacts:
paths: []
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
#################################################################
# #
# containers stage #
# #
#################################################################
# Build a container for each distribution + version. The ci-templates
# will re-use the containers if the tag doesn't change.
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:28@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '28'
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:29@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '29'
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
gitlab-ci: also build on CentOS 7.5 and 7.6
2019-05-24 10:48:20 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:30@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '30'
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
gitlab-ci: also build on CentOS 7.5 and 7.6
2019-05-24 10:48:20 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:31@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '31'
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
gitlab-ci: build with clang and do multiple builds in one test-step Also, let one docker image do multiple builds. We fetch a fedora docker image, and then install 250 MB of packages. That alone takes a lot of time and resources. Instead of running a large number of docker images that only do one build, let one image do several builds. Also, install ccache. Hopefully this way we can benefit from building the same sources multiple times. Also note that building docs does not work currently with clang, due to g-ir-scanner. See commit 05568860cce5332977d92b85f7c25b8ed646cd58.
2019-02-04 10:06:21 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:32@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '32'
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
gitlab-ci: add clang-format test on fedora 33 which run clang-format 11 Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-25 14:08:59 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:33@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '33'
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
gitlab: add .gitlab-ci.yml for gitlab CI See-also: https://docs.gitlab.com/ee/ci/yaml/
2018-10-15 11:17:22 +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
fedora:rawhide@container-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
gitlab-ci: use Fedora 30 to build documentation and archived tarball
2019-11-22 12:42:38 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:16.04@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '16.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
gitlab-ci: add "t_fedora:32" and by default build on Fedora 31
2020-02-21 10:23:52 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:18.04@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '18.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
gitlab-ci: enable fedora:33 build and generate pages on F32
2020-08-18 21:31:50 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:20.04@container-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
gitlab-ci: build release tarball and artifact it (cherry picked from commit 84e19c6ca9a921bb780d9109a93e338f50ede7eb)
2019-04-19 07:38:12 +00:00
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '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
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC: $UBUNTU_EXEC
gitlab-ci: add test with Fedora:latest image
2019-01-27 14:30:20 +00:00
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:devel@container-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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: 'devel'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
FDO_DISTRIBUTION_EXEC: $UBUNTU_EXEC
ubuntu:rolling@container-prep:
extends:
- .fdo.container-build@ubuntu
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: 'rolling'
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
gitlab-ci: add building on Fedora 31 And don't build Fedora 28 by default. It's aleady end of life. But for now keep it, so it can be triggered manually.
2019-09-25 09:28:19 +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
debian:9@container-prep:
extends:
- .fdo.container-build@debian
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '9'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC: $DEBIAN_EXEC
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +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
debian:10@container-prep:
extends:
- .fdo.container-build@debian
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '10'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
FDO_DISTRIBUTION_EXEC: $DEBIAN_EXEC
gitlab-ci: also build on CentOS 7.5 and 7.6
2019-05-24 10:48:20 +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
debian:testing@container-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
gitlab-ci: also build on CentOS 7.5 and 7.6
2019-05-24 10:48:20 +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
debian:sid@container-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
gitlab-ci: add more CentOS images for tests
2020-05-13 20:56:33 +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
centos:7.5.1804@container-prep:
extends:
- .fdo.container-build@centos
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '7.5.1804'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
FDO_DISTRIBUTION_EXEC: $CENTOS_EXEC
gitlab-ci: add more CentOS images for tests
2020-05-13 20:56:33 +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
centos:7.6.1810@container-prep:
extends:
- .fdo.container-build@centos
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '7.6.1810'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
FDO_DISTRIBUTION_EXEC: $CENTOS_EXEC
gitlab-ci: add more CentOS images for tests
2020-05-13 20:56:33 +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
centos:7.7.1908@container-prep:
extends:
- .fdo.container-build@centos
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '7.7.1908'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
FDO_DISTRIBUTION_EXEC: $CENTOS_EXEC
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +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
centos:7.8.2003@container-prep:
extends:
- .fdo.container-build@centos
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '7.8.2003'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
FDO_DISTRIBUTION_EXEC: $CENTOS_EXEC
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +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
centos:8.1.1911@container-prep:
extends:
- .fdo.container-build@centos
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '8.1.1911'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
FDO_DISTRIBUTION_EXEC: $CENTOS_EXEC
gitlab-ci: add manual build step to test on ubuntu:rolling and ubuntu:devel Rolling is the latest release (regardless of whether LTS), currently that would be 19.04. Devel is the next release, currently that would be 19.10. Add manual build steps to trigger those builds so we can manually verify that they pass.
2019-07-11 09:53:37 +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
#################################################################
# #
# container clean stage #
# run during the clean stage #
# #
#################################################################
#
# This stage will look for the container images we currently have in
# the registry and will remove any that are not tagged with the provided
# $container_image:$tag
#
# This job only runs for a scheduled pipeline.
#
# Go to your Profile, Settings, Access Tokens
# Create a personal token with 'api' scope, copy the value.
# Go to CI/CD, Schedules, schedule a monthly job.
# Define a variable of type File named AUTHFILE. Content is that token
# value.
.container-clean:
stage: container_clean
image: golang:alpine
before_script:
- apk add python3 py-pip git
- pip3 install git+http://gitlab.freedesktop.org/freedesktop/ci-templates
script:
- ci-fairy -v --authfile $AUTHFILE delete-image
--repository $FDO_DISTRIBUTION_NAME/$FDO_DISTRIBUTION_VERSION
--exclude-tag $FDO_DISTRIBUTION_TAG
dependencies: []
allow_failure: true
only:
- schedules
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:28@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '28'
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:29@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '29'
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:30@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '30'
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:31@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '31'
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:32@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '32'
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
fedora:33@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '33'
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
fedora:rawhide@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/fedora/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: 'rawhide'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:16.04@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/ubuntu/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '16.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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:18.04@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/ubuntu/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '18.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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:20.04@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/ubuntu/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '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
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
ubuntu:devel@container-clean:
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:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/ubuntu/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: 'devel'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
ubuntu:rolling@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/ubuntu/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: 'rolling'
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
debian:9@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/debian/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '9'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
debian:10@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/debian/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '10'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
debian:testing@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/debian/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: 'testing'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
debian:sid@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/debian/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: 'sid'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
centos:7.5.1804@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/centos/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '7.5.1804'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
centos:7.6.1810@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/centos/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '7.6.1810'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
centos:7.7.1908@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/centos/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '7.7.1908'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
centos:7.8.2003@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/centos/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '7.8.2003'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
centos:8.1.1911@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/centos/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '8.1.1911'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
#################################################################
# #
# build stage #
# #
#################################################################
.build@template:
stage: test
script:
- .gitlab-ci/build.sh
dependencies: []
#################################################################
# #
# test stage #
# #
#################################################################
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_fedora:28:
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '28'
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "fedora:28@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_fedora:29:
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '29'
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "fedora:29@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_fedora:30:
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '30'
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "fedora:30@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_fedora:31:
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '31'
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "fedora:31@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_fedora:32:
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '32'
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "fedora:32@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_fedora:33:
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
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- .nm_artifacts
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '33'
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:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "fedora:33@container-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
t_fedora:rawhide:
extends:
- .build@template
- .fdo.distribution-image@fedora
variables:
FDO_DISTRIBUTION_VERSION: 'rawhide'
FDO_DISTRIBUTION_TAG: $FEDORA_TAG
needs:
- "fedora:rawhide@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_ubuntu:16.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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '16.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
needs:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "ubuntu:16.04@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_ubuntu:18.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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '18.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
needs:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "ubuntu:18.04@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '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
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
needs:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "ubuntu:20.04@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
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
variables:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
FDO_DISTRIBUTION_VERSION: '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
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
needs:
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
- "ubuntu:devel@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
gitlab-ci: add ubuntu:20.04 test and reorder versions
2020-11-09 09:48:05 +00:00
t_ubuntu:rolling:
extends:
- .build@template
- .fdo.distribution-image@ubuntu
variables:
FDO_DISTRIBUTION_VERSION: 'rolling'
FDO_DISTRIBUTION_TAG: $UBUNTU_TAG
needs:
- "ubuntu:rolling@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
gitlab-ci: add manual build step to test on ubuntu:rolling and ubuntu:devel Rolling is the latest release (regardless of whether LTS), currently that would be 19.04. Devel is the next release, currently that would be 19.10. Add manual build steps to trigger those builds so we can manually verify that they pass.
2019-07-11 09:53:37 +00:00
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +00:00
t_debian:9:
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
variables:
FDO_DISTRIBUTION_VERSION: '9'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
needs:
- "debian:9@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +00:00
gitlab-ci: enable test build on Debian 10 (buster)
2019-07-10 10:29:48 +00:00
t_debian:10:
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
variables:
FDO_DISTRIBUTION_VERSION: '10'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
needs:
- "debian:10@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
gitlab-ci: enable test build on Debian 10 (buster)
2019-07-10 10:29:48 +00:00
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +00:00
t_debian:testing:
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
variables:
FDO_DISTRIBUTION_VERSION: 'testing'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
needs:
- "debian:testing@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
gitlab-ci: build on Ubuntu 16.04, 18.04 and Debian stretch (9), testing, sid https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/119 (cherry picked from commit 1ca380f69fe2c4958a557d5aaeff32b46c343cf9)
2019-04-18 06:46:53 +00:00
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
variables:
FDO_DISTRIBUTION_VERSION: 'sid'
FDO_DISTRIBUTION_TAG: $DEBIAN_TAG
needs:
- "debian:sid@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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:7.5.1804:
extends:
- .build@template
- .fdo.distribution-image@centos
variables:
FDO_DISTRIBUTION_VERSION: '7.5.1804'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
needs:
- "centos:7.5.1804@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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:7.6.1810:
extends:
- .build@template
- .fdo.distribution-image@centos
variables:
FDO_DISTRIBUTION_VERSION: '7.6.1810'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
needs:
- "centos:7.6.1810@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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:7.7.1908:
extends:
- .build@template
- .fdo.distribution-image@centos
variables:
FDO_DISTRIBUTION_VERSION: '7.7.1908'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
needs:
- "centos:7.7.1908@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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:7.8.2003:
extends:
- .build@template
- .fdo.distribution-image@centos
variables:
FDO_DISTRIBUTION_VERSION: '7.8.2003'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
needs:
- "centos:7.8.2003@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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:8.1.1911:
extends:
- .build@template
- .fdo.distribution-image@centos
variables:
FDO_DISTRIBUTION_VERSION: '8.1.1911'
FDO_DISTRIBUTION_TAG: $CENTOS_TAG
needs:
- "centos:8.1.1911@container-prep"
gitlab-ci: automatically run prep-container to fix hanging tests The goal is to run most distros only manually. However, it would be nice to avoid (manually) clicking twice to start the tests for one distro: once for the container preparation, and once for the actual test. Previously, the container prep part was set to manual and the actual test automatic. It worked almost as desired, except that this leads to the entire gitlab-ci pipeline be be in running state indefinitely. To fix that, always run the container prep steps. If the container is cached, this is supposed to be fast and cheap. Now only the actual tests are marked as "manual".
2020-11-11 07:50:00 +00:00
when: manual
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: merge "check-ci-script" test with static checks Certain parts of the code are entirely generated or must follow a certain format that can be enforced by a tool. These invariants must never fail: - ci-fairy generate-template (check-ci-script) - black python formatting - clang-format C formatting - msgfmt -vs On the other hand, we also have a checkpatch script that checks the current patch for common errors. These are heuristics and only depend on the current patch (contrary to the previous type that depend on the entire source tree). Refactor the gitlab-ci tests: - split "checkpatch" into "check-patch" and "check-tree". - merge the "check-ci-script" test into "check-tree".
2020-11-10 09:47:04 +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:
gitlab-ci: generate pages on Fedora 33 image On one image we do extra work, like generating documentation (gitlab-pages). The same image is currently also used for the "checkpatch" step. That step checks code formatting using clang-format. The formatting depends on the clang version, and we currently choose Fedora 33 as the desired version for formatting. It means, the "checkpatch" step requires Fedora 33. We could choose a different image for generating pages and run check patch. However, that might not be best. Just also generate the pages using Fedora 33.
2020-11-09 09:32:42 +00:00
- t_fedora:33
gitlab-ci: merge "check-ci-script" test with static checks Certain parts of the code are entirely generated or must follow a certain format that can be enforced by a tool. These invariants must never fail: - ci-fairy generate-template (check-ci-script) - black python formatting - clang-format C formatting - msgfmt -vs On the other hand, we also have a checkpatch script that checks the current patch for common errors. These are heuristics and only depend on the current patch (contrary to the previous type that depend on the entire source tree). Refactor the gitlab-ci tests: - split "checkpatch" into "check-patch" and "check-tree". - merge the "check-ci-script" test into "check-tree".
2020-11-10 09:47:04 +00:00
- .nm_artifacts_undo
stage: test
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:
- t_fedora:33
- .nm_artifacts_undo
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: test
script:
- date '+%Y%m%d-%H%M%S'; black --check . examples/python/gi/nm-wg-set
- 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
gitlab-ci: merge "check-ci-script" test with static checks Certain parts of the code are entirely generated or must follow a certain format that can be enforced by a tool. These invariants must never fail: - ci-fairy generate-template (check-ci-script) - black python formatting - clang-format C formatting - msgfmt -vs On the other hand, we also have a checkpatch script that checks the current patch for common errors. These are heuristics and only depend on the current patch (contrary to the previous type that depend on the entire source tree). Refactor the gitlab-ci tests: - split "checkpatch" into "check-patch" and "check-tree". - merge the "check-ci-script" test into "check-tree".
2020-11-10 09:47:04 +00:00
- date '+%Y%m%d-%H%M%S'; ci-fairy generate-template && git diff --exit-code
gitlab-ci: add test with Fedora:latest image
2019-01-27 14:30:20 +00:00
gitlab: add .gitlab-ci.yml for gitlab CI See-also: https://docs.gitlab.com/ee/ci/yaml/
2018-10-15 11:17:22 +00:00
pages:
stage: deploy
script:
- mv docs-html public
artifacts:
expire_in: 20 days
paths:
- public
only:
- master
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:
gitlab-ci: generate pages on Fedora 33 image On one image we do extra work, like generating documentation (gitlab-pages). The same image is currently also used for the "checkpatch" step. That step checks code formatting using clang-format. The formatting depends on the clang version, and we currently choose Fedora 33 as the desired version for formatting. It means, the "checkpatch" step requires Fedora 33. We could choose a different image for generating pages and run check patch. However, that might not be best. Just also generate the pages using Fedora 33.
2020-11-09 09:32:42 +00:00
- t_fedora:33
gitlab-ci: add "needs" for pages test It seems "pages" test does not get properly triggered, if only t_fedora:33 completes. It should, because the other distros are optional. Try to set "needs" to fix that.
2020-11-11 07:46:52 +00:00
needs:
- t_fedora:33
gitlab-ci: add scheduled pipeline to triage inactive issues and MRs
2020-03-18 15:01:30 +00:00
triage:issues:
stage: triage
gitlab-ci: use ruby:2.7 for triage pipeline This fixes the pipeline as 'gem' will be installed by default in the container image. Also fix wording and run gitlab-triage in debug mode to get more output.
2020-03-18 16:25:59 +00:00
image: ruby:2.7
gitlab-ci: add scheduled pipeline to triage inactive issues and MRs
2020-03-18 15:01:30 +00:00
script:
- gem install gitlab-triage
gitlab-ci: use ruby:2.7 for triage pipeline This fixes the pipeline as 'gem' will be installed by default in the container image. Also fix wording and run gitlab-triage in debug mode to get more output.
2020-03-18 16:25:59 +00:00
- gitlab-triage -d --token $API_TOKEN --source-id $SOURCE_ID
gitlab-ci: add scheduled pipeline to triage inactive issues and MRs
2020-03-18 15:01:30 +00:00
only:
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
- schedules
Reference in a new issue Copy permalink