It should be quite easy to adapt it to your project. I hope you find it useful.
Best regards,
—Guilherme
---
### Author:  [@fsimonis](https://discourse.cmake.org/u/fsimonis)
#### Post date: [April 2, 2026, 3:47pm UTC](https://discourse.cmake.org/t/integrating-cdash-submission-into-a-normal-ci/15587/4 "2026-04-02T15:47:05Z")
> [@benthevining](#):
>
> In practice, I do place a `CTestConfig.cmake` file in the repo root.
Do you generate this as part of the CI?
@amadio Thanks. This is a very good reference for a full script that ticks most of our boxes. The message grouping was on our mind, too. It helps to make the output a bit easier to read, but it doesn’t run individual steps.
---
### Author:  [@benthevining](https://discourse.cmake.org/u/benthevining)
#### Post date: [April 2, 2026, 4:20pm UTC](https://discourse.cmake.org/t/integrating-cdash-submission-into-a-normal-ci/15587/5 "2026-04-02T16:20:43Z")
> [@fsimonis](#):
>
> Do you generate this as part of the CI?
No, why would you? It’s not a mortal sin for there to be a CTestConfig.cmake file sitting in the repo root of any normal git clone. It has project-specific information, so it belongs in the project, IMHO.
---
### Author:  [@fsimonis](https://discourse.cmake.org/u/fsimonis)
#### Post date: [April 2, 2026, 5:48pm UTC](https://discourse.cmake.org/t/integrating-cdash-submission-into-a-normal-ci/15587/6 "2026-04-02T17:48:29Z")
[quote=“Ben Vining, post:5, topic:15587, username:benthevining”]
No, why would you?… It has project-specific information, so it belongs in the project, IMHO.
[/quote]
Some setting are run-specific though for example the name of the site/CI runner or the name of the build including configuration details etc.
Form my understanding, they also need to be part of the CTestConfig and it cannot depend on variables from the CMakeLists nor CMakeCache, so I need to patch or generate that file. And I don’t really want to patch files in the source directory based on some configuration in the binary directory.
---
### Author:  [@amadio](https://discourse.cmake.org/u/amadio)
#### Post date: [April 2, 2026, 6:02pm UTC](https://discourse.cmake.org/t/integrating-cdash-submission-into-a-normal-ci/15587/7 "2026-04-02T18:02:18Z")
My script runs the steps in sequence with the split sections for messages, as you pointed out, and always does a ctest\_submit at the end, without running subsequent steps if a step fails. The reason I decided to run the steps together is that the submit step needs the build name and other things which I detect in the beginning, so if I did the steps separately, I’d have to rerun parts of the script multiple times. You can, however, use CTEST\_ARG or optional arguments to customize that script to run only certain steps. I have an optional step that installs the project, which is enabled with -DINSTALL=1, for example. Similarly for enabling clang-tidy, sanitizers, valgrind, etc. There’s also a .ci/config.cmake with default options, and per-OS detection for customizations. You could use that for your various configurations.
For CTestConfig.cmake, we have one in the project’s top directory. If you need customizations per build, you could use environment variables in the set commands within your CTestConfig.cmake, or use a CTestConfig.cmake.in to generate one in the build directory or have it done by the CI as you said.
Have a look here for an easier to follow description of our CI:
> **[XRootD and FTS Workshop @ PIC (Barcelona)](https://indico.cern.ch/event/1542060/contributions/6732645/)**
>
> LOGIN to see the Zoom connection details. :) The 2025 XRootD and FTS workshop will take place on 13-17 October, 2025, at Hotel Exe Campus, Universitat Autonoma de Barcelona (UAB), Bellaterra (Barcelona), Spain. This event will be hosted by PIC, which...
Cheers,
---
### Author:  [@benthevining](https://discourse.cmake.org/u/benthevining)
#### Post date: [April 2, 2026, 6:16pm UTC](https://discourse.cmake.org/t/integrating-cdash-submission-into-a-normal-ci/15587/8 "2026-04-02T18:16:39Z")
No, the CTestConfig file contains only the following content:
```auto
set (CTEST_PROJECT_NAME ben-bot)
set (CTEST_NIGHTLY_START_TIME 01:00:00 UTC)
set (CTEST_SUBMIT_URL https://my.cdash.org/submit.php?project=ben-bot)
set (CTEST_DROP_SITE_CDASH TRUE)
```
All other settings should be specified elsewhere
---
### Author:  [@fsimonis](https://discourse.cmake.org/u/fsimonis)
#### Post date: [April 8, 2026, 12:20pm UTC](https://discourse.cmake.org/t/integrating-cdash-submission-into-a-normal-ci/15587/9 "2026-04-08T12:20:20Z")
> [@amadio](#):
>
> use a CTestConfig.cmake.in to generate one in the build directory
The CTestConfig.cmake isn’t picked up in the build directory (CMake 3.31.6).
> [@benthevining](#):
>
> All other settings should be specified elsewhere
OK. I think I finally figured out the chain of information:
1. The `ctest` calls rely on the `DartConfiguration.tcl`
2. The `DartConfiguration.tcl` is generated when `include(CTest)` is called.
3. The CTest module reads the `CTestConfig.cmake` in the root of the source directory and what the documentation refers to as `CTest module variable`.
So, setting up CDash support without a standalone ctest script is possible via
- Populating the `CTest module variables` in `CMakeLists.txt` before calling `include(CTest)`. This can be done by
- adding a `CTestConfig.cmake` to the root of your source directory,
- programmatically in the `CMakeLists.txt` using `set()`,
- by passing these via the CLI using `-D`, or
- by [prepopulating the cache](https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdoption-cmake-C) using `-C`.
- Skip `include(CTest)` and directly generate the `DartConfiguration.tcl` [following the format](https://cmake.org/cmake/help/latest/manual/ctest.1.html#dashboard-client-via-ctest-command-line) specification.