.gitlab-ci.yml

# It is assumed that the CI pipeline is executed in a docker.
# Importantly, not the single jobs are executed in a container but the whole gitlab-runner
# instance. See e.g. https://docs.gitlab.com/runner/install/docker.html

# Use the Makefile in the root folder of datafold to set up a gitlab CI runner docker.
# The only runner can run anywhere (only tested for Linux) with internet access (on a
# dedicated server, but also locally along the dev environment). Consider the following
# make targets
# * `make build_ci_image` -- to create the docker image (deriving from the gitlab-runner:latest docker image)
# * `make run_ci_container` -- start the container
# * `make register_gitlab_runner` -- register the gitlab-runner
# TODO: make PYTHON an environment variable

stages:
  - setup
  - test
  - code_analysis
  - deploy


variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
  PRE_COMMIT_DIR: "${CI_PROJECT_DIR}/.cache/pre-commit"
  VENV_DIR: "${CI_PROJECT_DIR}/.venv"
  PYTHON: "python"


cache:
  paths:
    - ${PIP_CACHE_DIR}
    - ${PRE_COMMIT_DIR}
    - ${VENV_DIR}


# https://gitlab.com/gitlab-org/gitlab/-/issues/33694#note_335120563
workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: never
    - when: always


# See keyword reference for the .gitlab-ci.yml file
# https://docs.gitlab.com/ee/ci/yaml/
setup_dependencies:
  stage: setup
  script:
    - make install_devdeps
    - make versions

unittests:
  stage: test
  script:
    - make clean_test
    - make unittest
  allow_failure: false
  coverage: /(?i)total.*? (100(?:\.0+)?\%|[1-9]?\d(?:\.\d+)?\%)$/
  artifacts:
    paths:
      - ./coverage/
    expire_in: 1 week
    when: on_success
  interruptible: true


functional_tests:
  script:
    - make tutorialtest
  allow_failure: false
  interruptible: true


code_checks:
  stage: code_analysis
  script:
    - make precommit
  allow_failure: true
  interruptible: true


docu_checks:
  stage: code_analysis
  script:
    - make clean_docs
    - make docs OPEN_DOCS_BROWSER=false
  except:
    - master
  allow_failure: true
  interruptible: true


docu_checks_urls:
  stage: code_analysis
  script:
    - make docs_linkcheck
  when: manual # not always ping all urls in the docs for each CI run
  except:
    - master
  allow_failure: true
  interruptible: true


install_check:
    stage: code_analysis
    script:
      - make test_install
    except:
      - master
    allow_failure: false
    interruptible: true


pages:
  stage: deploy
  script:
    - make clean_docs
    - make docs OPEN_DOCS_BROWSER=false DATAFOLD_TUTORIALS_EXECUTE=true OUTPUT_DOCS=./public
    # make sure the index.html file is in public/ (otherwise the docs page shows HTTP 404)
    - mv ./public/html/* ./public/
  artifacts:
    paths:
    - public
  rules:
    # from: https://forum.gitlab.com/t/how-to-setup-manual-job-from-feature-branch-that-runs-automatically-on-master/38892
    # always update pages if on master
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: always
    # manual option for dev branches
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
      when: manual
      allow_failure: true


# For infos on testPyPI see https://packaging.python.org/guides/using-testpypi/
# Note that
# 1) It is required to set the variables TWINE_USERNAME and TWINE_PASSWORD in gitlab CI/CD
# 2) The database for TestPyPI may be periodically pruned, so it can happen that user
#    accounts are deleted on testPyPI.
# 3) It is best to use the same account and password in testPyPI as for the "true PyPI".
#    This way the twine variables set up in point 1) can be re-used.
pypi_upload_test:
  stage: deploy
  script:
    - make test_pypi
  when: manual

pypi_upload:
  stage: deploy
  script:
    - make pypi
  only:
    - master
  when: manual