feat: cleanup caches for merged prs

[paulbalaji]

• feat: cleanup caches for merged prs
• force delete based on the sample workflow https://github.com/actions/cache/blob/main/tips-and-workarounds.md#force-deletion-of-caches-overriding-default-cache-eviction-policy

see it in action here: https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/10705157657/job/29679857473?pr=4429#step:3:30

[changeset-bot]

⚠️ No Changeset found

Latest commit: 710e247

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.22%. Comparing base (88d4c39) to head (710e247).
Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4429   +/-   ##
=======================================
  Coverage   73.22%   73.22%           
=======================================
  Files         100      100           
  Lines        1412     1412           
  Branches      178      178           
=======================================
  Hits         1034     1034           
  Misses        357      357           
  Partials       21       21           

Components	Coverage Δ
core	84.61% <ø> (ø)
hooks	72.38% <ø> (ø)
isms	78.31% <ø> (ø)
token	88.88% <ø> (ø)
middlewares	77.39% <ø> (ø)

[tkporter]

tbh I'm not certain, I assume we still run CI for PRs in the merge queue and that's why it takes so long? in which case does it make sense to clean up the cache when enqueuing a PR?

[paulbalaji]

it's just how GHA caches work, that the merge queue cache is derived from the target branch, and is separate to that of the branch being merged

[paulbalaji]

once a PR is enqueued, it goes into the merge queue, each PR in the merge queue is effectively a separate gh-readonly branch that can't use the same cache as the PR branch (since they're separate branches)

a big problem atm is we get into a state where the incoming branches should be able to pickup an existing cache but can't because GHA is evicting caches from main super aggressively

[paulbalaji]

please pull latest main after #4458 is merged to fix the cli-advanced-e2e test

[paulbalaji]

probs not required after moving to buildjet #4424