.gitlab-ci.yml

# This reusable CI script is licensed under the MIT license.
# See the complete license text at the end.

### Configuration section

# The versions of the compiler to test the project against.
# .build-matrix:
  # parallel:
    # https://docs.gitlab.com/ee/ci/yaml/README.html#parallel-matrix-jobs
    # matrix:
    # - OCAML_COMPILER: "4.00.1"
    # - OCAML_COMPILER: "4.01.0"
    # - OCAML_COMPILER: "4.02.1"
    # - OCAML_COMPILER: "4.02.3"
    # - OCAML_COMPILER: "4.03.0"
    # - OCAML_COMPILER: "4.04.2"
    # - OCAML_COMPILER: "4.05.0"
    # - OCAML_COMPILER: "4.06.1"
    # - OCAML_COMPILER: "4.07.1"
    # - OCAML_COMPILER: "4.08.1"
    # - OCAML_COMPILER: "4.09.1"
    # - OCAML_COMPILER: "4.10.0"

variables:
  OCAML_COMPILER: "4.14.1"
  CLEAN_OPAM_CACHE: "false"
  CLEAN_DUNE_CACHE: "false"
  # If CLEAN_OPAM_CACHE is set to "true", the opam switch from previous CI jobs
  # will not be reused.
  # If CLEAN_DUNE_CACHE is set to "true", the dune _build directory
  # from previous CI jobs will not be reused.

  # In particular, you can run a manual pipeline
  # with either variable set to "true" to purge a faulty cache.

  # To run a manual gitlab pipeline, on your project go to
  # "CI/CD" > pipelines, click "Run pipeline", the interface
  # then offers to override variables, so you can change the
  # value of any variable defined here.

  DUNE_BUILD_TARGETS: "@install"
  DUNE_TEST_TARGETS: "@tests/regression_tests/runtest" #"@runtest"
  DUNE_DOC_TARGETS: "" #"@doc"
  # If you make one of these variables empty (: ""),
  # the corresponding build step will be skipped.
  # Setting them to other values can refine the build
  # process, for example "@foo/runtest @bar/runtest" would only
  # run the tests inside directories 'foo/' and 'bar/'
  # (see Dune documentation on target aliases).

  GIT_SUBMODULE_STRATEGY: recursive

# This CI script is written to be portable across projects.
# None of the code below hardcodes project filenames,
# OCaml versions or other project-specific details.
#
# If you want to add new behavior for your project, we recommend
# trying to factorize it with project-agnostic code below,
# and project-specific or manually-overridable choices in the
# 'variables' section above.


### Hacking advice
#
# Reference documentation for Gitlab CI configuration files:
#  https://docs.gitlab.com/ee/ci/yaml/
#
# If you edit this file and make syntax errors, the default
# error messages will not help you, but Gitlab offers a "CI Lint"
# service that provides very nice error messages: