Skip to content

ci: add workflow to clean caches periodically#1807

Closed
8144225309 wants to merge 1 commit intobitcoin-core:masterfrom
8144225309:ci-clean-caches
Closed

ci: add workflow to clean caches periodically#1807
8144225309 wants to merge 1 commit intobitcoin-core:masterfrom
8144225309:ci-clean-caches

Conversation

@8144225309
Copy link
Contributor

@8144225309 8144225309 commented Jan 25, 2026 •
edited
Loading

Deletes all caches on the 1st and 15th of each month.

Fixes #1691

@8144225309 8144225309 mentioned this pull request Jan 25, 2026
Closed
real-or-random
real-or-random reviewed Jan 27, 2026
View reviewed changes
Copy link
Contributor

@real-or-random real-or-random left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

I'm a bit hesitant due to the actions: write permission, but I tend to think it's okay here. This workflow doesn't even have an input that could be attacker controlled. And actions restricts it to GitHub Actions stuff.

real-or-random
real-or-random approved these changes Jan 27, 2026
View reviewed changes
Copy link
Contributor

@real-or-random real-or-random left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK a27ae1a

@real-or-random
Copy link
Contributor

real-or-random commented Jan 27, 2026

cc @hebasto

hebasto
hebasto reviewed Jan 27, 2026
View reviewed changes
Copy link
Member

@hebasto hebasto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's shame that https://github.com/actions/cache does not provide an option to set a retention period explicitly.

I think we could avoid introducing a new workflow with the write permission by simply rotating the cache keys regularly. Feel free to grab a commit from this branch.

@real-or-random
Copy link
Contributor

real-or-random commented Jan 27, 2026 •
edited
Loading

I think we could avoid introducing a new workflow with the write permission by simply rotating the cache keys regularly.

That seems cleaner indeed.

edit: This means for this PR:

Approach NACK

@hebasto
Copy link
Member

hebasto commented Jan 27, 2026 •
edited
Loading

Unrelated to the changes in this PR, the current GCC snapshot has been failing self-tests since ed2924c7628343ff8b699f320a05c85bdb9c2837.

UPDATE: The issue should be fixed in a6c3c48148dd60a09ffab57019f163180c159d65.

@hebasto hebasto mentioned this pull request Feb 1, 2026
Merged
@hebasto
Copy link
Member

hebasto commented Feb 1, 2026

I think we could avoid introducing a new workflow with the write permission by simply rotating the cache keys regularly.

That seems cleaner indeed.

Done in #1816.

@real-or-random
Copy link
Contributor

real-or-random commented Feb 2, 2026

Let me close this in favor of #1816.

real-or-random added a commit that referenced this pull request Feb 2, 2026
@real-or-random
Merge #1816: ci: Rotate Docker cache keys
453949a 
2ccff6e ci: Add weekly schedule (Hennadii Stepanov)
2f18567 ci: Rotate Docker cache keys every 4 weeks (Hennadii Stepanov)
0ffb174 ci, docker: Fix LLVM repository signature failure (Hennadii Stepanov)

Pull request description:

  This is an alternative to #1807 that avoids introducing a new workflow with the write permissions.

  Closes #1691.

  The 4-week rotation interval was chosen based on the following [rationale](#1816 (comment)):
  > My thinking is that we may want to take only every fourth one. I assume this is still good enough to catch changes introduced by new compiler optimizations, and this is what we care about.
  >
  > We could just take the ISO week number mod 4. That results in an off-by-one error after every (rare) year with 53 ISO weeks, but ok, who cares... And if the cache is evicted for whatever other reason, we'll also get the most recent snapshot, but also that seems acceptable.

  ---

  **IMPORTANT NOTE:** Due to a mere coincidence, LLVM apt signatures became [rejected](llvm/llvm-project#153385) by Debian Trixie today. A commit containing a temporary workaround has been included to address this.

ACKs for top commit:
  real-or-random:
    ACK 2ccff6e

Tree-SHA512: c0362b107169d7cd7d36e0f7286d0bd183b734963beaa3915f198bedfd83f14222b779cb87eb6de2b1b940592954947d348a17a416e5db737a757397bd916447
@hebasto hebasto mentioned this pull request Feb 3, 2026
Merged
real-or-random added a commit that referenced this pull request Feb 3, 2026
@real-or-random
Merge #1818: ci: Enforce base-10 evaluation
c5da3bd 
4fb7ccf ci: Enforce base-10 evaluation (Hennadii Stepanov)

Pull request description:

  This PR is a follow-up to #1816. It enforces base-10 evaluation the week number to prevent Bash from interpreting weeks "08" and "09" as invalid octal numbers.

  It was present in my initial [proposal](#1807 (review)), but somehow I missed it in #1816.

ACKs for top commit:
  real-or-random:
    ACK 4fb7ccf

Tree-SHA512: dc6d1e5d692ac82616c5c64e1093c19693aa81d3b693834fb0999130b5e3357340b8ed0a5322cfa8d2f9fefbfeb8285abbd580662d257529d9d767afa009e9ef
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@real-or-random real-or-random real-or-random approved these changes

+1 more reviewer

@hebasto hebasto hebasto left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

ci

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

ci: Clean the cache regularly to test on new compiler snapshots

3 participants

@8144225309 @real-or-random @hebasto