Recommended Naming Conventions for CDash Integration
To prevent dashboard fragmentation and maintain a clean build history in CDash when using Spack, you should adopt a hierarchical naming convention for the --cdash-track and --cdash-build flags. Because CDash treats these values as unique identifiers for grouping results, inconsistent strings create redundant entries that obscure systemic trends.
Standardizing --cdash-track
The --cdash-track flag defines the high-level category of the build. To avoid fragmentation across multiple CI pipelines, use a static, environment-based identifier. The recommended format is:
[Environment]-[Architecture]-[Compiler]
Example: --cdash-track "production-x86_64-gcc12"
By keeping the track name constant for a specific environment configuration, all subsequent builds for that environment are grouped together, allowing you to track the stability of a specific stack over time rather than creating a new track for every single CI run.
Structuring --cdash-build
The --cdash-build flag identifies the specific iteration of the build. To maintain a clear history without creating excessive noise, use a monotonic or timestamped identifier linked to your version control system (VCS) or CI build number.
The recommended structure is:
[CI_Build_Number]_[Commit_Hash]
Example: --cdash-build "421_a1b2c3d"
This approach ensures that each build is unique and traceable back to a specific code state, but avoids using randomly generated strings that make the CDash history difficult to navigate.
Implementation and Verification
Since Spack's flag behavior can vary between versions, verify the available options for your current installation before deploying the pipeline:
spack install --help | grep cdash
Verification Steps:
- Execute a test install with a dummy track and build name.
- Log into the CDash server and confirm that the build appears under the expected track.
- Run a second build with the same
--cdash-track but a different --cdash-build to ensure they are grouped correctly in the dashboard.
Assumptions and Constraints
This recommendation assumes you are using a version of Spack that supports direct CDash upload flags. If your environment requires a custom wrapper to convert Spack logs to CTest XML, these flags may be ignored in favor of the wrapper's internal logic. Additionally, be aware that very large Spack installation logs may be truncated by some CDash server configurations.
Diagnostic Detail Needed: Are you using the native Spack CDash flags, or is there an intermediary CTest wrapper script handling the XML generation?
spack