4 The repository contains DockerFiles and GitLab Runner configuration
5 files to support automated testing and documentation builds.
6 General information on configuring GitLab CI pipelines can be found
7 in the official `Gitlab documentation <https://docs.gitlab.com/ee/ci/yaml/>`_.
9 The GitLab CI configuration entry point is the :file:`.gitlab-ci.yml` file
10 at the root of the source tree.
11 Configuration templates are found in the files in the
12 :file:`admin/ci-templates/` directory.
14 Docker images used by GitLab Runner are available on `Docker Hub <https://hub.docker.com/u/gromacs>`__.
15 Images are (re)built manually using details in :file:`admin/containers`.
17 This documentation is incomplete, pending resolution of :issue:`3275`.
19 .. todo:: Expand this documentation to resolve :issue:`3275`
24 .. todo:: Discuss the distinct characteristics of |Gromacs| CI pipelines to relevant to job configuration.
26 .. todo:: Comment on the number of pipelines that can be or which are likely to be running at the same time.
30 Full automated testing is only available for merge requests originating from
31 branches of the main https://gitlab.com/gromacs/gromacs repository.
32 GitLab CI pipelines created for forked repositories will include fewer jobs
33 in the testing pipeline. Non-trivial merge requests may need to be issued
34 from a branch in the ``gromacs`` project namespace in order to receive
35 sufficient testing before acceptance.
40 At the root of the repository, :file:`.gitlab-ci.yml` defines the stages and
41 some default parameters, then includes files from :file:`admin/gitlab-ci/` to
42 define jobs to be executed in the pipelines.
44 Note that job names beginning with a period (``.``) are
45 `"hidden" <https://docs.gitlab.com/ee/ci/yaml/#hidden-keys-jobs>`_.
46 Such jobs are not directly eligible to run, but may be used as templates
47 via the `*extends* job property <https://docs.gitlab.com/ee/ci/yaml/#extends>`_.
52 Refer to https://docs.gitlab.com/ee/ci/yaml for complete documentation on
53 GitLab CI job parameters, but note the following GROMACS-specific conventions.
58 Used by several of our templates to prepend shell commands to
59 a job *script* parameter.
60 Avoid using *before-script* directly, and be cautious
61 about nested *extends* overriding multiple *before_script* definitions.
64 There is no global default, but jobs that build software will likely
65 set *cache*. To explicitly unset *cache* directives, specify a job
66 parameter of ``cache: {}``.
67 Refer to `GitLab docs <https://docs.gitlab.com/ee/ci/yaml/#cache>`__
68 for details. In particular, note the details of cache identity according
69 to `cache:key <https://docs.gitlab.com/ee/ci/yaml/#cachekey>`__
72 Part of the tool chain configuration. Instead of setting *image*
73 directly, *extend* a *.use_<toolchain>* template from
74 :file:`admin/gitlab-ci/global.gitlab-ci.yml`
80 *Job* parameters for controlling the circumstances under which jobs run.
81 (Some key words may have different meanings when occurring as elements
82 of other parameters, such as *archive:when*, to which this note is not
84 Instead of setting any of these directly in a job definition, try to use
85 one of the pre-defined behaviors (defined as ``.rules:<something>`` in
86 :file:`admin/gitlab-ci/global.gitlab-ci.yml`).
87 Errors or unexpected behavior will occur if you specify more than one
88 *.rules:...* template, or if you use these parameters in combination
89 with a *.rules...* template.
90 To reduce errors and unexpected behavior, restrict usage of these controls
91 to regular job definitions (don't use in "hidden" or parent jobs).
94 Jobs that can only run in the |Gromacs| GitLab CI Runner infrastructure
95 should require the ``k8s-scilifelab`` tag.
96 These include jobs that specify Kubernetes configuration variables or
97 require special facilities, such as GPUs or MPI.
98 Note that the *tag* controls which Runners are eligible to take a job.
99 It does not affect whether the job is eligible for addition to a particular pipeline.
100 Additional *rules* logic should be used to make sure that jobs with the
101 ``k8s-scilifelab`` do not become eligible for pipelines launched outside
102 of the |Gromacs| project environment.
103 See, for instance, :term:`CI_PROJECT_NAMESPACE`
106 Many job definitions will add or override keys in *variables*.
107 Refer to `GitLab <https://docs.gitlab.com/ee/ci/yaml/#variables>`__
108 for details of the merging behavior. Refer to :ref:`variables` for local usage.
110 Schedules and triggers
111 ~~~~~~~~~~~~~~~~~~~~~~
113 Pipeline `schedules <https://gitlab.com/help/ci/pipelines/schedules>`__ are
114 configured through the GitLab web interface.
115 Scheduled pipelines may provide different variable definitions through the
116 environment to jobs that run under the ``schedules``
117 `condition <https://gitlab.com/help/ci/pipelines/schedules#using-only-and-except>`__.
119 Nightly scheduled pipelines run against ``master`` and *release* branches in
120 the GROMACS repository.
125 In addition to the templates in the main job definition files,
126 common "mix-in" functionality and behavioral templates are defined in
127 :file:`admin/gitlab-ci/global.gitlab-ci.yml`.
129 Jobs beginning with ``.use-`` provide mix-in behavior, such as boilerplate for
130 jobs using a particular tool chain.
132 Jobs beginning with a `parameter <https://docs.gitlab.com/ee/ci/yaml>`__
133 name allow parameters to be set in a single place for common job characteristics.
134 If providing more than a default parameter value, the job name should be suffixed
135 by a meaningful descriptor and documented within
136 :file:`admin/gitlab-ci/global.gitlab-ci.yml`
143 1. Indicate the purpose of the job.
144 2. Indicate relationships between multi-stage tasks.
145 3. Distinguish jobs in the same stage.
146 4. Distinguish job definitions throughout the configuration.
148 Jobs may be reassigned to different stages over time, so including the stage
149 name in the job name is not helpful, generally. If tags like "pre" and "post,"
150 or "build" and "test" are necessary to distinguish phases of, say, "webpage,"
151 then such tags can be buried at the end of the job name.
153 Stylistically, it is helpful to use delimiters like ``:`` to distinguish the
154 basic job name from qualifiers or details. Also consider
155 `grouping jobs <https://docs.gitlab.com/ee/ci/pipelines/index.html#grouping-jobs>`__
159 Updating regression tests
162 Changes in |GROMACS| that require changes in regression-tests are notoriously hard,
163 because a merge request that tests against the non-updated version of the
164 regression tests will necessarily fail, while updating regression tests while
165 the current change is not integrated into master, might cause other
166 merge request pipelines to fail.
168 The solution is a new regression-test branch or commit, uploaded to gitlab.
169 Then set that regression test branch with REGRESSIONTESTBRANCH or
170 the specific commit with REGRESSIONTESTCOMMIT when
171 running the specific pipeline that requires the regressiontest-update.
172 See below on how to set variables for specific pipelines.
177 The GitLab CI framework, GitLab Runner, plugins, and our own scripts set and
178 use several `variables <https://docs.gitlab.com/ee/ci/variables/README.html>`__.
180 Default values are available from the ``.variables:default`` definition in
181 :file:`admin/gitlab-ci/global.gitlab-ci.yml`.
182 Many of the mix-in / template jobs provide additional or overriding definitions.
183 Other variables may be set when making final job definitions.
185 Variables may control the behvior of GitLab-CI (those beginning with ``CI_``),
186 GitLab Runner and supporting infrastructure, or may be used by job definitions,
187 or passed along to the environment of executed commands.
189 *variables* keys beginning with ``KUBERNETES_`` relate to the GitLab Runner
190 `Kubernets executor <https://docs.gitlab.com/runner/executors/kubernetes.html#the-kubernetes-executor>`__
192 Other important variable keys are as follows.
196 Distinguishes pipelines created for repositories in the ``gromacs``
197 GitLab project space. May be used to pre-screen jobs to determine
198 whether |Gromacs| GitLab infrastructure is available to the pipeline
199 before the job is created.
201 COMPILER_MAJOR_VERSION
202 Integer version number provided by toolchain mix-in for convenience and
205 CMAKE_COMPILER_SCRIPT
206 CMake command line options for a tool chain. A definition is provided by
207 the mix-in toolchain definitions (e.g. ``.use-gcc8``) to be appended to
208 :command:`cmake` calls in a job's *script*.
211 Provide CMake command line arguments to define GROMACS MPI build options.
214 Read-only environment variable that can be checked to see if a job is
215 executing in a pipeline for preparing a tagged release.
216 Can be set when launching pipelines via the GitLab web interface.
217 For example, see *rules* mix-ins in :file:`admin/gitlab-ci/global.gitlab-ci.yml`.
220 List additional OS package requirements. Used in *before_script* for some
221 mix-in job definitions to install additional software dependencies. If
222 using such a job with *extends*, override this variable key with a
223 space-delimited list of packages (default: ``""``). Consider proposing a
224 patch to the base Docker images to include the dependency to reduce
225 pipeline execution time.
228 Use this branch of the regressiontests rather than master to allow for
229 merge requests that require updated regression tests with valid CI tests.
232 Use this commit to the regressiontests rather than the head on master to
233 allow for merge requests that require updated regression tests with
237 .. todo:: Define common variables.
238 ``BUILD_DIR``, ``INSTALL_DIR``, ``CACHE_FALLBACK_KEY``, ...
243 Variables for individual piplelines are set in the gitlab interface under
244 ``CI/CD``→``Pipelines``. Then chose in the top right corner ``Run Piplelines``.
245 Under ``Run for``, the desired branch may be selected, and variables may be set