NetworkManager/.gitlab-ci/ci.template

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

257 lines
8.4 KiB
Plaintext
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:
{# You're looking at the template here, so you can ignore the below
warning. This is the right file to edit #}
########################################
# #
# THIS FILE IS GENERATED, DO NOT EDIT #
# Edit .gitlab-ci/ci.template instead #
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
# #
# Regenerate with:
# TEMPLATE_SHA="$(sed -n 's/^.templates_sha: *\&template_sha *\([0-9a-f]\+\) .*/\1/p' ./.gitlab-ci/ci.template)"
# pip3 install "git+http://gitlab.freedesktop.org/freedesktop/ci-templates@$TEMPLATE_SHA"
# ci-fairy generate-template
#
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
########################################
.templates_sha: &template_sha ffe4d1b10aab7534489f0c4bbc4c5899df17d3f2 # 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:
{% for distro in distributions|sort(attribute="name") %}
# {{ distro.name.capitalize() }} container builder template
- project: 'freedesktop/ci-templates'
ref: *template_sha
file: '/templates/{{distro.name}}.yml'
{% endfor %}
stages:
- prep
- test
- deploy
- triage
- container_clean
variables:
FDO_UPSTREAM_REPO: NetworkManager/NetworkManager
GIT_DEPTH: 1
# These tags should be updated each time the list of packages is updated
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
# changing these will force rebuilding the associated image
# Note: these tags have no meaning and are not tied to a particular NM version
#
# This is done by running `ci-fairy generate-template` and possibly bumping
# ".default_tag".
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
{% for distro in distributions %}
{{"%-13s"| format(distro.name.upper() + '_TAG:')}}'{{distro.tag}}-{{
(ci_fairy.hashfiles('./.gitlab-ci/config.yml',
'./.gitlab-ci/ci.template',
'./.gitlab-ci/' + distro.base_type + '-install.sh',
'./contrib/' + distro.base_type + '/REQUIRED_PACKAGES'))[0:12]
}}'
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
{% endfor %}
{% for distro in distributions %}
{{"%-13s"| format(distro.name.upper() + '_EXEC:')}}'bash .gitlab-ci/{{distro.base_type}}-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
{% endfor %}
.nm_artifacts:
variables:
NM_BUILD_TARBALL: 1
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
artifacts:
expire_in: 5 days
when: always
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
paths:
- docs-html
- NetworkManager-1*.tar.xz
- NetworkManager-1*.src.rpm
- nm-test.log
.nm_artifacts_debug:
artifacts:
expire_in: 5 days
when: always
paths:
- nm-test.log
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
#################################################################
# #
# containers stage #
# #
#################################################################
# Build a container for each distribution + version. The ci-templates
# will re-use the containers if the tag doesn't change.
{% for distro in distributions %}
{% for version in distro.versions %}
{{distro.name}}:{{version}}@container-prep:
extends:
- .fdo.container-build@{{distro.name}}
stage: prep
variables:
GIT_STRATEGY: none
FDO_DISTRIBUTION_VERSION: '{{version}}'
FDO_DISTRIBUTION_TAG: ${{distro.name.upper()}}_TAG
FDO_DISTRIBUTION_EXEC: ${{distro.name.upper()}}_EXEC
{% endfor %}
{% endfor %}
#################################################################
# #
# 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
{% for distro in distributions %}
{% for version in distro.versions %}
{{distro.name}}:{{version}}@container-clean:
extends:
- .container-clean
variables:
GIT_STRATEGY: none
CURRENT_CONTAINER_IMAGE: $CI_REGISTRY_IMAGE/{{distro.name}}/$FDO_DISTRIBUTION_VERSION:$FDO_DISTRIBUTION_TAG
FDO_DISTRIBUTION_VERSION: '{{version}}'
FDO_DISTRIBUTION_TAG: ${{distro.name.upper()}}_TAG
{% endfor %}
{% endfor %}
#################################################################
# #
# build stage #
# #
#################################################################
.build@template:
stage: test
script:
- env
- r=0
- .gitlab-ci/run-test.sh 2>&1 | tee /tmp/nm-test.log || r=$?
- mv /tmp/nm-test.log .
- exit $r
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
dependencies: []
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
#################################################################
# #
# test stage #
# #
#################################################################
{% for distro in distributions %}
{% for version in distro.versions %}
t_{{distro.name}}:{{version}}:
extends:
- .build@template
- .fdo.distribution-image@{{distro.name}}
{% if distro.name == pages_build.name and
version == pages_build.version %}
- .nm_artifacts
{% else %}
- .nm_artifacts_debug
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
{% endif %}
variables:
FDO_DISTRIBUTION_VERSION: '{{version}}'
FDO_DISTRIBUTION_TAG: ${{distro.name.upper()}}_TAG
{# Where we have extra_variables defined, add them to the list #}
{% if distro.build is defined and distro.build.extra_variables is defined %}
{% for var in distro.build.extra_variables %}
{{var}}
{% endfor %}
{% endif %}
needs:
- "{{distro.name}}:{{version}}@container-prep"
{% if not version in distro.get('always', []) and (distro.name != pages_build.name or version != pages_build.version) %}
when: manual
{% endif %}
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
{% endfor %}
{% endfor %}
#################################################################
# #
# specific jobs #
# #
#################################################################
check-patch:
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
extends:
- .fdo.distribution-image@{{pages_build.name}}
variables:
FDO_DISTRIBUTION_VERSION: '{{pages_build.version}}'
FDO_DISTRIBUTION_TAG: ${{pages_build.name.upper()}}_TAG
needs:
- "{{pages_build.name}}:{{pages_build.version}}@container-prep"
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:
- .fdo.distribution-image@{{pages_build.name}}
variables:
FDO_DISTRIBUTION_VERSION: '{{pages_build.version}}'
FDO_DISTRIBUTION_TAG: ${{pages_build.name.upper()}}_TAG
needs:
- "{{pages_build.name}}:{{pages_build.version}}@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
stage: test
script:
- date '+%Y%m%d-%H%M%S'; contrib/scripts/nm-python-black-format.sh --check
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
- date '+%Y%m%d-%H%M%S'; git ls-files -z -- 'po/*.po' | xargs -0 -n1 msgfmt -vc
- date '+%Y%m%d-%H%M%S'; contrib/scripts/nm-code-format.sh -n
- date '+%Y%m%d-%H%M%S'; ci-fairy generate-template && git diff --exit-code
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
pages:
stage: deploy
script:
- mv docs-html public
artifacts:
expire_in: 20 days
paths:
- public
only:
- main
gitlab CI: switch to using ci-templates ci-templates encourages building specific containers that can be re-used: - containers are re-used across pipelines, producing consistent results - containers are re-used by contributors since they will use the upstream containers for their MR, thus guaranteeing the same results. Containers are automatically rebuild whenever the respective FDO_DISTRIBUTION_TAG changes. This is particularly interesting now that Docker Hub will introduce pull limits. This CI script consists of a config file and a jinja2 template, simply running 'ci-fairy generate-template' produces the .gitlab-ci.yml. ci-fairy is part of the freedesktop.org ci-templates and can be pip installed, see the check-ci-script job. Functional changes to the previous script: - new job: check-ci-script, verifies that our gitlab-ci.yml is the one generated by the sources - Added distributions: - Fedora 33 - The actual work is now down by a set of scripts in .gitlab-ci/, specifically: - .gitlab-ci/build.sh is the previous do_build job - .gitlab-ci/{fedora|debian}-install.sh are the previous {fedora|debian}_install jobs symlinks are in place for centos and ubuntu Why the scripts instead of steps in the CI? Easer to reading and reproduce. With the containers being static, it's easy to pull one locally and re-run the CI job to reproduce an issue. Having everything in a single script makes that trivial. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/664
2020-10-29 23:19:11 +00:00
dependencies:
- t_{{pages_build.name}}:{{pages_build.version}}
needs:
- t_{{pages_build.name}}:{{pages_build.version}}
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
triage:issues:
stage: triage
image: ruby:2.7
script:
- gem install gitlab-triage
- gitlab-triage -d --token $API_TOKEN --source-id $SOURCE_ID
only:
- schedules