ci: Mitigate network issues in native Windows job #35024

pull hebasto wants to merge 3 commits into bitcoin:master from hebasto:260407-vcpkg-dl-cache changing 1 files +16 −13
  1. hebasto commented at 3:30 PM on April 7, 2026: member

    This PR mitigates network issues when vcpkg downloads source tarballs by caching the entire vcpkg/downloads directory.

    Closes #34996.

  2. hebasto added the label Windows on Apr 7, 2026
  3. hebasto added the label Tests on Apr 7, 2026
  4. DrahtBot commented at 3:30 PM on April 7, 2026: contributor

    <!--e57a25ab6845829454e8d69fc972939a-->

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    <!--021abf342d371248e50ceaed478a90ca-->

    Reviews

    See the guideline for information on the review process.

    Type Reviewers
    ACK maflcko, sedited

    If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

    <!--5faf32d7da4f0f540f40219e4f7537a3-->

  5. hebasto commented at 4:43 PM on April 7, 2026: member

    The size of windows-native-dll-vcpkg-downloads is about 1.2 GB, compared to 470 MB for windows-native-dll-vcpkg-tools.

    Perhaps we could exclude vcpkg/downloads/tools from the cache.

  6. hebasto marked this as a draft on Apr 7, 2026
  7. hebasto force-pushed on Apr 7, 2026
  8. hebasto commented at 9:23 PM on April 7, 2026: member

    Perhaps we could exclude vcpkg/downloads/tools from the cache.

    Done.

    The size of windows-native-dll-vcpkg-downloads is about 1.2 GB...

    It's 800 MB now.

  9. maflcko commented at 6:11 AM on April 8, 2026: member

    Can you explain why the tools were previously cached, what they are, and why it is fine to no longer cache them?

  10. hebasto commented at 7:53 AM on April 8, 2026: member

    Can you explain why the tools were previously cached...

    To skip downloading and unpacking them whenever possible.

    ... what they are...

    They are Windows binaries used for building packages for the target triplet. Here are the contents of the vcpkg/downloads/tools directory from the CI:

    $ ls -l ~/AppData/Local/vcpkg/downloads/tools
total 164
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:37 jom
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:46 meson-1.8.2-3d2461
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:49 msys2
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:37 nasm
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:29 ninja
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:37 perl
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:29 powershell-core-7.5.4-windows
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:46 python
drwxr-xr-x 1 runneradmin 197121 0 Apr  7 14:46 win_bison

    ... and why it is fine to no longer cache them?

    It is a tradeoff. The downloaded tool archives are now cached along with the package source tarballs. However, vcpkg has to unpack them on every run.

  11. in .github/workflows/ci.yml:262 in cd8092df88 outdated 
     262 | -          path: ~/AppData/Local/vcpkg/downloads/tools
 263 | -          key: ${{ github.job }}-vcpkg-tools-${{ github.run_id }}
 264 | -          restore-keys: ${{ github.job }}-vcpkg-tools-
 265 | +          path: |
 266 | +            ~/AppData/Local/vcpkg/downloads/*
 267 | +            !~/AppData/Local/vcpkg/downloads/tools
    maflcko commented at 8:43 AM on April 8, 2026:

    Is there a need to set a path on a download? Wouldn't it be easier to just set the correct path on upload only?

    hebasto commented at 2:35 PM on April 9, 2026:

    Yes, there is a need. The path input participates in cache entity identification. Therefore, a pair of actions/cache/restore and actions/cache/save must have the exact same path configured, or it will result in a cache miss.

  12. in .github/workflows/ci.yml:290 in cd8092df88 
     291 |          with:
 292 | -          path: ~/AppData/Local/vcpkg/downloads/tools
 293 | -          key: ${{ github.job }}-vcpkg-tools-${{ github.run_id }}
 294 | +          path: |
 295 | +            ~/AppData/Local/vcpkg/downloads/*
 296 | +            !~/AppData/Local/vcpkg/downloads/tools
    maflcko commented at 8:45 AM on April 8, 2026: 
                !~/AppData/Local/vcpkg/downloads/tools  # Cache the tools once as archives, but not redundantly in extracted form.

    nit: Maybe add a comment here, as per my question and your answer?

    hebasto commented at 2:28 PM on April 9, 2026:

    Thanks! The comment has been added.

  13. ci, refactor: Reuse primary key in `actions/cache/save`
    This avoids code duplication and improves readability.
    88bbf2ad33
  14. ci: Cache `vcpkg/downloads` folder in native Windows CI job
    The new cache is keyed with the hash of 'vcpkg.json', which reduces
cache storage consumption compared to keying by run ID.

The `vcpkg/downloads/tools` subdirectory is excluded to further save
space.
    dc93091083
  15. hebasto force-pushed on Apr 9, 2026
  16. hebasto marked this as ready for review on Apr 9, 2026
  17. hebasto commented at 2:36 PM on April 9, 2026: member

    The feedback from @maflcko has been addressed.

  18. in .github/workflows/ci.yml:214 in dc93091083 outdated 
     210 | @@ -211,7 +211,7 @@ jobs:
 211 |          with:
 212 |            path: ${{ env.CCACHE_DIR }}
 213 |            # https://github.com/actions/cache/blob/main/tips-and-workarounds.md#update-a-cache
 214 | -          key: ${{ github.job }}-${{ matrix.job-type }}-ccache-${{ github.run_id }}
 215 | +          key: ${{ steps.ccache-cache.outputs.cache-primary-key }}
    maflcko commented at 4:09 PM on April 9, 2026:

    you claim this is a refactor, but it would be good to link to the relevant docs, so that reviewers can confirm this.

    to me this looks like dropping the run_id, making it impossible to save a new cache?

    hebasto commented at 11:26 AM on April 11, 2026:

    you claim this is a refactor, but it would be good to link to the relevant docs, so that reviewers can confirm this.

    Sure.

    From the docs:

    • cache-primary-key - Cache primary key passed in the input to use in subsequent steps of the workflow.

    to me this looks like dropping the run_id, making it impossible to save a new cache?

    It now refers to:https://github.com/bitcoin/bitcoin/blob/dc9309108381cd5704b8e9eedc931bd5337dad78/.github/workflows/ci.yml#L192

    If you think cache-primary-key is confusing, Iā€™m happy to drop that commit.

  19. maflcko commented at 7:03 AM on April 13, 2026: member

    Note for Maintainers: To properly populate the new CI cache, all current vcpkg binary caches must be cleared to trigger a rebuild.

    Would it not be easier and clearer to pick a new name for the new cache?

  20. ci: Rename vcpkg binary cache entity to force rebuild 09c0e37789
  21. hebasto commented at 11:33 AM on April 13, 2026: member

    Note for Maintainers: To properly populate the new CI cache, all current vcpkg binary caches must be cleared to trigger a rebuild.

    Would it not be easier and clearer to pick a new name for the new cache?

    Thanks! Done.

  22. DrahtBot added the label CI failed on Apr 13, 2026
  23. maflcko commented at 3:40 PM on April 13, 2026: member

    review ACK 09c0e3778998eece67a908711efdac44ed3d3630 šŸ“¢

    <details><summary>Show signature</summary>

    Signature:

    untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 09c0e3778998eece67a908711efdac44ed3d3630 šŸ“¢
RRwSVexeMqLj/eb1FyUZqhz3Iay3uPWRPi6Mxp2/s7OqYsgtSvDZD2Hw3w1MlR3B74xykHEvLttPcuni2M1VCw==

    </details>

  24. DrahtBot removed the label CI failed on Apr 13, 2026
  25. sedited approved
  26. sedited commented at 10:33 AM on April 19, 2026: contributor

    utACK 09c0e3778998eece67a908711efdac44ed3d3630

  27. sedited merged this on Apr 19, 2026
  28. sedited closed this on Apr 19, 2026
  29. hebasto deleted the branch on Apr 19, 2026
  30. hebasto commented at 12:39 PM on April 20, 2026: member

    Hmm, the windows-native-dll-vcpkg-downloads cache was successfully saved yesterday:

    Cache saved with key: windows-native-dll-vcpkg-downloads-10b54c5a23d7f316a997f1ffa95a48c85318ffb3895a9a21dceef6021fabc38e

    But today it is not available:

    Cache not found for input keys: windows-native-dll-vcpkg-downloads-10b54c5a23d7f316a997f1ffa95a48c85318ffb3895a9a21dceef6021fabc38e
  31. willcl-ark commented at 12:49 PM on April 20, 2026: member

    Not sure what the root cause is here, but assuming eviction/thrashing.

    If so we could try increasing cache size: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching#increasing-cache-size ?

  32. maflcko commented at 10:06 AM on April 21, 2026: member

    Not sure what the root cause is here, but assuming eviction/thrashing.

    Yeah, I presume the macos task is fast enough to build twice when other tasks are not yet done, so it can easily eat 2 * 2 * 2 GB = 8 GB with ccache data out of the 10 GB. Another ccache from the arm task will already overflow the limit, without even giving any space for the Windows cache.

    So I guess the cache needs to be bumped, or #34474 reverted for the GHA runners?

  33. sedited referenced this in commit 75f2bf1011 on Apr 25, 2026
  34. willcl-ark commented at 7:51 PM on April 28, 2026: member

    Opened #35176 one approach to fix the cache churn we see here.

Contributors
hebastoDrahtBotmaflckoseditedwillcl-ark
Labels
WindowsTests
Linked (view graph)
#34996 ci: intermittent failure in Windows CI#35176 ci: reduce ccache size on GHA runners
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-02 03:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me