Skip to content

Pipeline

Jump to bottom
Fabian Wein edited this page May 9, 2025 · 5 revisions

Here we collect hints and tricks with respect to the Gitlab CI pipeline

The pipeline generally tests compiling openCFS on various platforms and runs the test suite. One can run the pipeline on any branch. One can only merge to the master branch via a merge request with a passed pipeline.

The pipeline can also create closed builds (with proprietary cfsdeps) and the max build (cfsdeps disabled in the default configuration). The pipeline also generate deployable binaries (default build) for Linux and Windows.

The pipeline has several modes, the two most important are:

  • automatic mode when a merge request is not in draft mode
  • manually running a brach which is not related to a merge request not in draft mode

All pipelines run via docker images from gitlab and have given maximal run time.

Stages

Not all stages are always shown, depending on the pipeline mode. These stages depend on the previous stage to succeed if it is running.

  • check: here the branch is analyzed to detect necessary stages
  • platform: optional test to build openCFS on a set of Linux distributions
  • cfsdeps: build and cache precompiled default cfsdeps if they do not exist yet in the cache)
  • build: build cfsdeps with different compilers on Linux and once on Windows.
  • test: with some of the build the test suite is run in different configurations. These need to pass
  • test_extra: additional test suite configurations which are allowed to fail

cfsdeps

All built cfsdeps in this stage are directly written to the cache. When the docker run time is not sufficient to build all tests, re-running the pipeline is likely to finish the job.

See under automatic mode below on how to trigger building the cfsdeps stage manually.

build

The build jobs use the precompiled cfsdeps cache. The max and closed builds need to add some cfsdeps. The cfsdeps build here are only written to the cache if the build job succeeds.

In case the precompiled cfsdeps are missing (cache is invalid, but cfsdeps stage was not triggered), all cfsdeps are build here. Usually this will fail to exceeded runtime. The only solution is to manually enable the cfsdeps stage (see also under automatic mode below). Also for other cases, where the build stage fails while building cfsdeps, enforcing running the cfsdeps stage is often the solution.

test

some have properties set in their CMakeLists.txt. You may use the the script tests.py in Testsuite/share, check with --help for the options.

./tests.py /Users/fwein/code/cfs/Testsuite
[...]
CMakeLists.txt with property 'slow': 50
CMakeLists.txt with property 'unstable': 33
CMakeLists.txt with property 'broken': 18
CMakeLists.txt with no property '${TEST_LABELS}': 655
-> use --list to list the items

We use the labels 'unstable' and 'broken' to select the test cases. Unfortunately some untagged tests also fail from time to time. In that case you may try to re-run that specific test via the button in the pipeline page.

Automatic mode for a merge request not in draft mode

Whenever a push to that merge request happens, the pipeline is started. To prevent this (e.g. when you exchange code via that branch between local systems), edit the merge request and set it to draft.

The pipeline in that mode attempts to detect which stages are necessary.

You may add labels (Label -> Edit) and select

  • clear-cache
  • build-cfsdeps

To properly activate these labels, you need to run the pipeline from the merge request and not from the gitlab Project -> CFS -> Pipelines link!

From the merge request header go to Pipelines (x) and from there select Run Pipeline

select_pipeline_in_merge_request

run_new_pipeline

Clone this wiki locally