Revision fb3f87feafd46f5c8480b300c1bcf386b699d23e authored by Alexander Kruppa on 28 May 2021, 15:28:36 UTC, committed by Alexander Kruppa on 28 May 2021, 15:29:36 UTC
1 parent 4ef6307
.gitlab-ci.yml
# see also ci/debug.sh
stages:
- build
- early
- thorough
- publish
image: gcc
# took inspiration from https://blog.callr.tech/building-docker-images-with-gitlab-ci-best-practices/
# however I'm not sure if/how the "latest" tagging actually works.
# Note that the name of each section is significant, as the file
# ci/001-environment.sh sets some important environment variables based
# on what it finds. E.g. it reacts to "with gcc", "expensive checks",
# "coverage tests", and so on.
# We're using a few features from gitlab yaml:
#
# - [yaml anchors](https://docs.gitlab.com/ce/ci/yaml/#anchors)
# - manual disable of pipeline elements, which we do more or less by hand
# (finer grained than the ["skip ci"
# syntax](https://docs.gitlab.com/ee/ci/yaml/#skip-pipeline))
#
# Much desired: https://gitlab.com/gitlab-org/gitlab/-/issues/23605
############################################################################
# This template is used so that if the magic words "skip some ci" are
# found in the git commit, then the whole pipeline becomes manual.
.common-template: &common-template
rules:
- if: $CI_COMMIT_MESSAGE =~ /skip some ci/
when: manual
allow_failure: false
- when: on_success
retry:
max: 2
when: runner_system_failure
# see also https://gitlab.com/gitlab-org/gitlab/-/issues/201845 regarding
# the pipeline deduplication
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
- when: always
############################################################################
# The jobs that do checks.
#
# Basically, much of the work is done in shell scripts for convenience,
# and they're grouped in the template below.
.checks-script: &checks-script
- ci/01-conf.sh
- ci/02-build1.sh
- ci/02-build2.sh
- ci/03-check.sh
.checks-junit-report: &checks-junit-report
artifacts:
reports:
junit: junit.xml
checks with gcc:
<<: *common-template
stage: early
image: gcc:latest
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks on alpine system with gcc:
<<: *common-template
stage: early
image: alpine:latest
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks on debian system with 32-bit gcc:
<<: *common-template
stage: early
image: debian
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks using cmake directly with gcc:
<<: *common-template
stage: early
image: alpine
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks on debian10 system with gcc:
<<: *common-template
stage: early
image: debian:10
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks on debian9 system with gcc:
<<: *common-template
stage: early
image: debian:9
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks on opensuse system with gcc:
<<: *common-template
stage: early
image: opensuse/leap
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks with clang:
<<: *common-template
image: debian:testing
stage: early
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
checks with icc:
<<: *common-template
image: intel/oneapi-hpckit:latest
stage: early
tags:
- icc
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
expensive checks with gcc:
<<: *common-template
stage: thorough
# do not start it prematurely, in case previous jobs failed
image: gcc:latest
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
<<: *checks-junit-report
############################################################################
# coverage. Actually, this is not really dependent on checks, after all.
# It does depend on the availability of the coverage images, though!
#
coverage tests on checks with gcc:
<<: *common-template
stage: thorough
# do not start it prematurely, in case previous jobs failed
image: alpine:latest
before_script:
- ci/00-prepare-docker.sh
script:
- *checks-script
artifacts:
paths:
- coverage-*.info
- coverage-*.json
expire_in: 1 week
# The json coverage reports for different runs are imported, provided we
# get the needs/artifacts combination right.
#
# https://stackoverflow.com/questions/38140996/how-can-i-pass-artifacts-to-another-stage
# https://docs.gitlab.com/ee/ci/yaml/#artifact-downloads-with-needs
#
# Once this job has run, the job artifacts, and in particular the html
# rendering of the coverage report, can be downloaded using links that
# are formed according to the following rules:
#
# https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-the-latest-artifacts
#
# Actually it took me a while to figure out the correct url. For the
# master branch, we want: https://gitlab.inria.fr/cado-nfs/cado-nfs/-/jobs/artifacts/master/file/coverage/index.html?job=merge+coverage+tests
#
# The good thing is that we don't need to play dirty tricks with gitlab
# pages and subdirectories. As it turns out, the final rendered page does
# show up under cado-nfs.gitlabpages.inria.fr, but we do not need to care
# about it.
merge coverage tests:
<<: *common-template
stage: publish
needs:
- job: coverage tests on checks with gcc
artifacts: true
# list more of these...
# This image has gcovr installed
image: alpine:latest
before_script:
- ci/00-prepare-docker.sh
script:
- ci/09-merge-coverage.sh
artifacts:
paths:
- coverage
- coverage.tar.gz
expire_in: 30 days
reports:
cobertura: coverage.xml
############################################################################
# Tests on slow machines and/or shell executors. They depend on nothing.
# # It would be possible to run the following test on arm64 as well, but my
# # only runner is an allwinner CPU with 2G of RAM, and it takes more than
# # two hours :-(. I think I would have to reduce the test surface first.
# # - arm64
# #
# # # very slow machines run with the shell executor anyway.
# # # 00-prepare-shell.sh can only check if software is present.
# run on very slow machines:
# <<: *common-template
# stage: thorough
# needs: []
# tags:
# - raspberry
# before_script:
# - ci/00-prepare-shell.sh
# script:
# - *checks-script
# <<: *checks-junit-report
# in fact, this one should be quick !
checks on osx system:
<<: *common-template
# do it early. It's one of our quickest runners.
stage: early
needs: []
tags:
- osx
before_script:
- ci/00-prepare-shell.sh
script:
- *checks-script
<<: *checks-junit-report
checks on freebsd12.2 system with gcc:
variables:
GIT_SUBMODULE_STRATEGY: recursive
<<: *common-template
stage: thorough
# do not start it prematurely, in case previous jobs failed
# needs: []
tags:
- freebsd-tanker
script:
- make -C ci/utilities/tanker
- ci/50-libvirt-wrap-tests.sh freebsd:12.2 ci/40-testsuite.sh
# https://gitlab.com/gitlab-org/gitlab/-/issues/15603 should be
# implemented someday. We would like to have it, to make sure that the
# cleanup sequence is called no matter what.
checks on freebsd13.0 system with gcc:
variables:
GIT_SUBMODULE_STRATEGY: recursive
<<: *common-template
stage: thorough
# do not start it prematurely, in case previous jobs failed
# needs: []
tags:
- freebsd-tanker
script:
- make -C ci/utilities/tanker
- ci/50-libvirt-wrap-tests.sh freebsd:13.0 ci/40-testsuite.sh
# "cache" is only when the runners have a notion of available cache
# server, it seems. Don't do that for now.
# cache:
# # paths:
# - "*.o"
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...