ci: misc improvements

[PastaPastaPasta]

Issue being fixed or feature implemented

See commits, but also:

Currently we fetch the entire history which takes about 15 seconds (https://github.com/dashpay/dash/actions/runs/13297199526/job/37131957876); with this patch, we fetch 50 commits of history and the ref develop only, resulting in the step taking only ~2 seconds. (https://github.com/PastaPastaPasta/dash/actions/runs/13300061362/job/37139947716)

Additionally, run unit tests in a dedicated step. May as well, gives better access to viewing ccache stats, and gives idea of how long unit tests are running.

Finally, compress and cleanup ccache. Github only gives us 10 gigs of caching, so whatever we can do to make that more efficient and make cache misses due to a cache being evicted less likely, I think are important

What was done?

How Has This Been Tested?

CI

Breaking Changes

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

[coderabbitai]

Walkthrough

The pull request modifies the GitHub Actions workflow in .github/workflows/build-src.yml. The fetch-depth parameter in the "Checkout code" step is increased from 0 to 50, allowing for more commit history to be retrieved. A new command, git fetch -fu origin develop:develop, is added to the "Initial setup" step to ensure the latest changes from the develop branch are fetched prior to checking out the current commit. The step for building the source is renamed from "Build source and run unit tests" to "Build source," and a new step for running unit tests is introduced after the build process. Additional commands for managing the ccache, specifically ccache -X 9 and ccache -c, are included in the build step. The overall structure of the workflow remains unchanged, with no alterations to the declarations of exported or public entities.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[knst]

why don't make it fetch-depth: 1 ?

[PastaPastaPasta]

because we have to fetch the entire PR history / up to develop, for stuff like clang-diff-format linter and scripted diffs and whatnot

[kwvg]

Should we have some mechanism to warn pull requests with >50 commits that they should consolidate or split their PRs to be under this limit?

[knst]

let's put 999 then? 999 is not really a lot (less than 1 major release), but it will cover for sure big PRs.
Performance to make clone with 999 commits should be still fast.

Examples of PR with big amount of commits:
109 commits - #4752
111 commits - #4512

[kwvg]

Works for me, I was going to suggest something lower like 128 since there really is little reason for a PR that large to exist but since we aren't implementing a warning mechanism, 999 is more than enough to cover any PR, sane or otherwise.

[PastaPastaPasta]

Honestly; no. I don't ever want to merge a PR more than 50 commits :D

[UdjinM6]

It increases the fetch-depth parameter from 0 to 50 in the "Checkout code" step, meaning that more commit history is now retrieved during checking out the repository code.

@coderabbitai is wrong here:

    # Number of commits to fetch. 0 indicates all history for all branches and tags.
    # Default: 1
    fetch-depth: ''

source https://github.com/actions/checkout?tab=readme-ov-file#usage

Going from 0 to 50 means going from all commits to up to 50 of them i.e. it's same or less commit history, not more of it.

[coderabbitai]

@UdjinM6 Thank you for the correction. You are absolutely right. I misinterpreted the fetch-depth parameter - setting it to 0 fetches all history, while setting it to 50 fetches only up to 50 commits, thus reducing the amount of history retrieved. This aligns perfectly with the PR's goal of optimizing CI time. I'll regenerate the summary with the correct interpretation.

---

✏️ Learnings added

Learnt from: UdjinM6
URL: https://github.com/dashpay/dash/pull/6575

Timestamp: 2025-02-13T07:36:17.414Z
Learning: In GitHub Actions checkout action, fetch-depth: 0 fetches all commit history for all branches and tags, while a positive number like fetch-depth: 50 fetches only that many recent commits, which is useful for CI optimization.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

✅ Actions performed

Summary regeneration triggered.

[UdjinM6]

Could probably get rid of some git commands now UdjinM6@133018f https://github.com/UdjinM6/dash/actions/runs/13303037024.

However, I'm not 100% sure fetch-depth changes in general are going to work correctly... Could break git merge-base based scripts, see PR description in #6428.

[PastaPastaPasta]

@UdjinM6 I don't think that commit will work in a PR context; I think it'll only work in a push context

[UdjinM6]

@UdjinM6 I don't think that commit will work in a PR context; I think it'll only work in a push context

I tried testing it by merging this PR + my suggestion into develop in my repo and creating another PR and it turns out that this PR breaks GH CI on develop: https://github.com/UdjinM6/dash/actions/runs/13317182118/job/37194741201

To fix this we could simply ask git to ignore its internal fetch checks:

-u
--update-head-ok
By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it.

https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt--u

It does say that

you are not supposed to use it

but it should be safe to do this in GH CI imo. Here is what it looks like: UdjinM6@674855a https://github.com/UdjinM6/dash/actions/runs/13319312731.

Now back to the original idea - pls check UdjinM6#22. It's a dummy PR to test 133018f. I don't see any issues 🤷‍♂️

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

.github/workflows/build-src.yml (2)

64-76: Integrate ccache Cleanup into the Build Step.
Renaming the build step to "Build source" and adding the commands ccache -X 9 and ccache -c optimizes the cache management by ensuring the cache is capped and cleaned, which is important given the 10 GB caching limit. Please confirm that setting the cache to "9" (presumably 9GB) meets your project’s requirements compared to the previously defined CCACHE_SIZE="400M". Inline comments explaining the intent of these ccache commands could be beneficial for future maintainers.

---

77-83: Separate and Clarify Unit Test Execution.
Introducing a dedicated "Run unit tests" step improves the CI overall by decoupling build and test processes, thereby enhancing visibility into unit test performance and ccache statistics. Ensure that the environment setup (sourcing matrix.sh) remains consistent with the build step, and consider whether additional error handling or timeout settings might be useful.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 525baac and 657438a.

📒 Files selected for processing (1)

• .github/workflows/build-src.yml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (1)

• GitHub Check: Build container / Build container

🔇 Additional comments (2)

.github/workflows/build-src.yml (2)

31-31: Optimize Checkout History Fetch Depth.
The change to fetch-depth: 50 significantly reduces the clone time by limiting the commit history fetched, which aligns with the PR's performance optimization goals. Verify that 50 commits are sufficient for all tooling (e.g., clang-diff-format and scripted diffs) as expected.

---

36-37: Ensure Latest 'develop' Branch is Fetched.
Adding git fetch -fu origin develop:develop in the Initial setup step helps guarantee that the latest changes from the develop branch are available for the CI. This is a useful safeguard to maintain consistency before the build begins.

[UdjinM6]

ACK 657438a

[kwvg]

utACK 657438a