Skip to content

ci: make ccache effective and observable, shallow checkout, add cache… - #7756

Open
MrLi000001 wants to merge 1 commit into
deepmodeling:developfrom
MrLi000001:ci/ccache-observability
Open

ci: make ccache effective and observable, shallow checkout, add cache…#7756
MrLi000001 wants to merge 1 commit into
deepmodeling:developfrom
MrLi000001:ci/ccache-observability

Conversation

@MrLi000001

Copy link
Copy Markdown

… warmer

Measured on the self-hosted runners, the Build step of the same workflow ranges from 2.7 min (warm ccache) to 37.5 min (stale ccache), and a full-history checkout took ~12 min on cache-cold runners.

  • Set ccache --max-size=30G (default ~10G is tight for -O3 -g builds) and print ccache -s before/after the build so hit rates are visible in every run log (if: always()).
  • fetch-depth: 0 -> 1; CMake only runs 'git log -1' for commit info.
  • Add cache_warmer.yml: on every push to develop, build (without tests) on both the X64 and gpu pools so /tmp/ccache stays primed with the latest develop. This prevents the first PR runs after a big refactor merge from all paying a full rebuild.

Reminder

  • I have read AGENTS.md and docs/developers_guide/agent_governance.md.
  • I have linked an issue or explained why this PR does not need one.
  • I have added adequate unit tests and/or case tests, or explained why not.
  • I have listed the exact verification commands run and their results.
  • I have described user-visible behavior changes, including INPUT parameter changes.
  • I have explained core-module impact for ESolver, HSolver, ElecState, Hamilt, Operator, Psi, or other source/ changes.
  • I have requested any needed governance exception below.

Linked Issue

Fix #

Unit Tests and/or Case Tests for my changes

  • Commands run:
  • Result summary:
  • Checks not run, with reason:

What's changed?

  • Example: brief summary of the user-visible or developer-facing change.

Governance Notes

  • INPUT/docs changes:
  • Core module impact:
  • Exceptions requested:

… warmer

Measured on the self-hosted runners, the Build step of the same workflow
ranges from 2.7 min (warm ccache) to 37.5 min (stale ccache), and a
full-history checkout took ~12 min on cache-cold runners.

- Set ccache --max-size=30G (default ~10G is tight for -O3 -g builds)
  and print ccache -s before/after the build so hit rates are visible
  in every run log (if: always()).
- fetch-depth: 0 -> 1; CMake only runs 'git log -1' for commit info.
- Add cache_warmer.yml: on every push to develop, build (without tests)
  on both the X64 and gpu pools so /tmp/ccache stays primed with the
  latest develop. This prevents the first PR runs after a big refactor
  merge from all paying a full rebuild.
@mohanchen mohanchen added GPU & DCU & HPC GPU and DCU and HPC related any issues Compile & CICD & Docs & Dependencies Issues related to compiling ABACUS Refactor Refactor ABACUS codes labels Aug 2, 2026
@Stardust0831

Stardust0831 commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

The shallow checkout and ccache statistics are useful, but I suggest splitting out the cache warmer. It is not yet clear whether /tmp/ccache persists across jobs and nodes in the dynamic runner pool, so one warmer may only warm a single node while consuming an additional GPU. It also builds the default seven CUDA architectures, while #7753 uses sm_70, so those CUDA cache entries will not be effectively reused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Compile & CICD & Docs & Dependencies Issues related to compiling ABACUS GPU & DCU & HPC GPU and DCU and HPC related any issues Refactor Refactor ABACUS codes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants