ENH: Add collapsible CI log sections for dashboard phases

[hjmjohnson]

Summary

• Adds ci_section_start() / ci_section_end() helper functions to itk_common.cmake
• Wraps configure, build, test, coverage, memcheck, and submit phases in collapsible log sections
• Detects CI environment via standard env vars and emits platform-appropriate markers:
  • GitHub Actions: ::group:: / ::endgroup::
  • Azure DevOps: ##[group] / ##[endgroup]
  • GitLab CI: ANSI escape section_start / section_end with [collapsed=true]
  • Local/other: plain --- Title --- delimiters

Motivation

Dashboard CI logs can be very long, making it hard to find the relevant phase (e.g., jumping straight to test failures). Collapsible sections let developers expand only the phase they care about.

References

• GitLab CI job log sections
• GitHub Actions grouping log lines
• Azure DevOps formatting commands

Test plan

• Verify collapsible sections appear correctly in GitHub Actions CI logs
• Verify collapsible sections appear correctly in Azure DevOps CI logs
• Verify local runs show plain --- Title --- delimiters

🤖 Generated with Claude Code

[hjmjohnson]

@thewtex, @blowekamp, @dzenanz I am hoping that this will make navigating the CI infrastructure easier by breaking up the testing/building phases into sub-sections that can be hidden.

I'd love you feedback on this suggestion. I'll be away from the office for the next week, so my responses may be slow.

[blowekamp]

Is there a sample run to look at someplace?

I get the problem you are trying to solve, with the difficulty with the logs. And using the groups look like a nice approach.

I have wanted to split the ctest steps into senate CI steps. The current driver monolithically does all steps. CTest has Start, Update, Configure, Build, Test, Coverage, MemCheck, and Submit steps, were submit cat be run after many of the steps or in parts. Just having separate configure, build and test steps in the CI would help along too IMHO. This would do a similar thing.

I am not sure parsing the xml in the cmake code is the right things to do. Perhaps using that python script in the dashboard branch, and directly calling it similar to the other PR would better keep components separated.

[hjmjohnson]

I am not sure parsing the xml in the cmake code is the right things to do. Perhaps using that python script in the dashboard branch, and directly calling it similar to the other PR would better keep components separated.

@blowekamp One benefit of parsing the XML is that it clearly list the exact warning or error that causes the build indicate failure AFTER the regular expressions had been filtered out. It should make adding specific regex easier to debug.

I like your idea of moving the python script to the dashboard branch and making it part of the dashboard steps. I'll try that next week after some more testing in this draft mode.

[hjmjohnson]

Attempt to use dashboard to review this PR

• DO NOT MERGE: Test collapsible CI log sections and build diagnostics #5974