# 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"