1# see also ci/debug.sh 2 3stages: 4 - build 5 - early 6 - thorough 7 - publish 8 9image: gcc 10 11# took inspiration from https://blog.callr.tech/building-docker-images-with-gitlab-ci-best-practices/ 12# however I'm not sure if/how the "latest" tagging actually works. 13 14# Note that the name of each section is significant, as the file 15# ci/001-environment.sh sets some important environment variables based 16# on what it finds. E.g. it reacts to "with gcc", "expensive checks", 17# "coverage tests", and so on. 18 19# We're using a few features from gitlab yaml: 20# 21# - [yaml anchors](https://docs.gitlab.com/ce/ci/yaml/#anchors) 22# - manual disable of pipeline elements, which we do more or less by hand 23# (finer grained than the ["skip ci" 24# syntax](https://docs.gitlab.com/ee/ci/yaml/#skip-pipeline)) 25# 26# Much desired: https://gitlab.com/gitlab-org/gitlab/-/issues/23605 27 28############################################################################ 29# This template is used so that if the magic words "skip some ci" are 30# found in the git commit, then the whole pipeline becomes manual. 31.common-template: &common-template 32 rules: 33 - if: $CI_COMMIT_MESSAGE =~ /skip some ci/ 34 when: manual 35 allow_failure: false 36 - when: on_success 37 retry: 38 max: 2 39 when: runner_system_failure 40 41# see also https://gitlab.com/gitlab-org/gitlab/-/issues/201845 regarding 42# the pipeline deduplication 43workflow: 44 rules: 45 - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS 46 when: never 47 - when: always 48 49############################################################################ 50# The jobs that do checks. 51# 52# Basically, much of the work is done in shell scripts for convenience, 53# and they're grouped in the template below. 54 55.checks-script: &checks-script 56 - ci/01-conf.sh 57 - ci/02-build.sh 58 - ci/03-check.sh 59 60.checks-junit-report: &checks-junit-report 61 artifacts: 62 reports: 63 junit: junit.xml 64 65checks with gcc: 66 <<: *common-template 67 stage: early 68 image: gcc:latest 69 before_script: 70 - ci/00-prepare-docker.sh 71 script: 72 - *checks-script 73 <<: *checks-junit-report 74 75checks on alpine system with gcc: 76 <<: *common-template 77 stage: early 78 image: alpine:latest 79 before_script: 80 - ci/00-prepare-docker.sh 81 script: 82 - *checks-script 83 <<: *checks-junit-report 84 85checks on debian system with 32-bit gcc: 86 <<: *common-template 87 stage: early 88 image: debian 89 before_script: 90 - ci/00-prepare-docker.sh 91 script: 92 - *checks-script 93 <<: *checks-junit-report 94 95checks using cmake directly with gcc: 96 <<: *common-template 97 stage: early 98 image: alpine 99 before_script: 100 - ci/00-prepare-docker.sh 101 script: 102 - *checks-script 103 <<: *checks-junit-report 104 105checks on debian10 system with gcc: 106 <<: *common-template 107 stage: early 108 image: debian:10 109 before_script: 110 - ci/00-prepare-docker.sh 111 script: 112 - *checks-script 113 <<: *checks-junit-report 114 115checks on debian9 system with gcc: 116 <<: *common-template 117 stage: early 118 image: debian:9 119 before_script: 120 - ci/00-prepare-docker.sh 121 script: 122 - *checks-script 123 <<: *checks-junit-report 124 125checks on opensuse system with gcc: 126 <<: *common-template 127 stage: early 128 image: opensuse/leap 129 before_script: 130 - ci/00-prepare-docker.sh 131 script: 132 - *checks-script 133 <<: *checks-junit-report 134 135checks with clang: 136 <<: *common-template 137 image: silkeh/clang:latest 138 stage: early 139 before_script: 140 - ci/00-prepare-docker.sh 141 script: 142 - *checks-script 143 <<: *checks-junit-report 144 145checks with icc: 146 <<: *common-template 147 image: intel/oneapi-hpckit:latest 148 stage: early 149 tags: 150 - icc 151 before_script: 152 - ci/00-prepare-docker.sh 153 script: 154 - *checks-script 155 <<: *checks-junit-report 156 157expensive checks with gcc: 158 <<: *common-template 159 stage: thorough 160 # do not start it prematurely, in case previous jobs failed 161 image: gcc:latest 162 before_script: 163 - ci/00-prepare-docker.sh 164 script: 165 - *checks-script 166 <<: *checks-junit-report 167 168############################################################################ 169# coverage. Actually, this is not really dependent on checks, after all. 170# It does depend on the availability of the coverage images, though! 171# 172coverage tests on checks with gcc: 173 <<: *common-template 174 stage: thorough 175 # do not start it prematurely, in case previous jobs failed 176 image: alpine:latest 177 before_script: 178 - ci/00-prepare-docker.sh 179 script: 180 - *checks-script 181 artifacts: 182 paths: 183 - coverage-*.info 184 - coverage-*.json 185 expire_in: 1 week 186 187 188# The json coverage reports for different runs are imported, provided we 189# get the needs/artifacts combination right. 190# 191# https://stackoverflow.com/questions/38140996/how-can-i-pass-artifacts-to-another-stage 192# https://docs.gitlab.com/ee/ci/yaml/#artifact-downloads-with-needs 193# 194# Once this job has run, the job artifacts, and in particular the html 195# rendering of the coverage report, can be downloaded using links that 196# are formed according to the following rules: 197# 198# https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-the-latest-artifacts 199# 200# Actually it took me a while to figure out the correct url. For the 201# master branch, we want: https://gitlab.inria.fr/cado-nfs/cado-nfs/-/jobs/artifacts/master/file/coverage/index.html?job=merge+coverage+tests 202# 203# The good thing is that we don't need to play dirty tricks with gitlab 204# pages and subdirectories. As it turns out, the final rendered page does 205# show up under cado-nfs.gitlabpages.inria.fr, but we do not need to care 206# about it. 207merge coverage tests: 208 <<: *common-template 209 stage: publish 210 needs: 211 - job: coverage tests on checks with gcc 212 artifacts: true 213 # list more of these... 214 # This image has gcovr installed 215 image: alpine:latest 216 before_script: 217 - ci/00-prepare-docker.sh 218 script: 219 - ci/09-merge-coverage.sh 220 artifacts: 221 paths: 222 - coverage 223 - coverage.tar.gz 224 expire_in: 30 days 225 reports: 226 cobertura: coverage.xml 227 228############################################################################ 229# Tests on slow machines and/or shell executors. They depend on nothing. 230 231# # It would be possible to run the following test on arm64 as well, but my 232# # only runner is an allwinner CPU with 2G of RAM, and it takes more than 233# # two hours :-(. I think I would have to reduce the test surface first. 234# # - arm64 235# # 236# # # very slow machines run with the shell executor anyway. 237# # # 00-prepare-shell.sh can only check if software is present. 238# run on very slow machines: 239# <<: *common-template 240# stage: thorough 241# needs: [] 242# tags: 243# - raspberry 244# before_script: 245# - ci/00-prepare-shell.sh 246# script: 247# - *checks-script 248# <<: *checks-junit-report 249 250# in fact, this one should be quick ! 251checks on osx system: 252 <<: *common-template 253 # do it early. It's one of our quickest runners. 254 stage: early 255 needs: [] 256 tags: 257 - osx 258 before_script: 259 - ci/00-prepare-shell.sh 260 script: 261 - *checks-script 262 <<: *checks-junit-report 263 264checks on freebsd12.2 system with gcc: 265 variables: 266 GIT_SUBMODULE_STRATEGY: recursive 267 <<: *common-template 268 stage: thorough 269 # do not start it prematurely, in case previous jobs failed 270 # needs: [] 271 tags: 272 - freebsd-tanker 273 script: 274 - make -C ci/utilities/tanker 275 - ci/50-libvirt-wrap-tests.sh freebsd:12.2 ci/40-testsuite.sh 276 # https://gitlab.com/gitlab-org/gitlab/-/issues/15603 should be 277 # implemented someday. We would like to have it, to make sure that the 278 # cleanup sequence is called no matter what. 279 280checks on freebsd13.0 system with gcc: 281 variables: 282 GIT_SUBMODULE_STRATEGY: recursive 283 <<: *common-template 284 stage: thorough 285 # do not start it prematurely, in case previous jobs failed 286 # needs: [] 287 tags: 288 - freebsd-tanker 289 script: 290 - make -C ci/utilities/tanker 291 - ci/50-libvirt-wrap-tests.sh freebsd:13.0 ci/40-testsuite.sh 292 293# checks with the default shipped compiler as well (which is clang) 294checks on freebsd13.0 system with clang: 295 variables: 296 GIT_SUBMODULE_STRATEGY: recursive 297 <<: *common-template 298 stage: thorough 299 # do not start it prematurely, in case previous jobs failed 300 # needs: [] 301 tags: 302 - freebsd-tanker 303 script: 304 - make -C ci/utilities/tanker 305 - ci/50-libvirt-wrap-tests.sh freebsd:13.0 ci/40-testsuite.sh 306 307coverity on debian10 system with gcc: 308 # override the common template. 309 rules: 310 - if: $CI_COMMIT_MESSAGE =~ /skip some ci/ 311 when: manual 312 allow_failure: false 313 - if: $CI_COMMIT_BRANCH && ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "coverity") 314 when: always 315 - when: never 316 stage: early 317 image: debian:10 318 before_script: 319 - ci/00-prepare-docker.sh 320 script: 321 - curl -o /tmp/cov-analysis-linux64.tgz 322 https://scan.coverity.com/download/linux64 323 --form project=$COVERITY_SCAN_PROJECT_NAME 324 --form token=$COVERITY_SCAN_TOKEN 325 - tar xfz /tmp/cov-analysis-linux64.tgz 326 - ci/01-conf.sh 327 - cov-analysis-linux64-*/bin/cov-build --dir cov-int ci/02-build.sh 328 - tar cfz cov-int.tar.gz cov-int 329 - curl https://scan.coverity.com/builds?project=$COVERITY_SCAN_PROJECT_NAME 330 --form token=$COVERITY_SCAN_TOKEN 331 --form email=$COVERITY_SCAN_USER_EMAIL 332 --form file=@cov-int.tar.gz 333 --form version="`git describe --tags`" 334 --form description="`git describe --tags` / $CI_COMMIT_TITLE / $CI_COMMIT_REF_NAME:$CI_PIPELINE_ID" 335 336# "cache" is only when the runners have a notion of available cache 337# server, it seems. Don't do that for now. 338# cache: 339# # paths: 340# - "*.o" 341