ci: Migrate to detect-versions with namespaced cache keys #1063
No reviewers
Jade
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status/Blocked
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
To-Merge
Wont fix
old/ci/cd
old/rust
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!1063
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tom/detect-versions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This replaces the local
detect-runner-osaction with externaldetect-versions@v1to lower reliance on custom actions.While updating the cache keys, I've added architecture detection for future cross-platform support, and namespaced all cache keys with
continuwuity-prefix for collision safety on runners.To match, cache mount IDs in Dockerfiles have been updated with the new namespacing convention, so cache isolation is consistent across all CI/builds.
Was cache collisions an issue we were running into? AFAK they're already split by repo
@ -81,2 +80,3 @@key: continuwuity-renovate-osv-cache-${{ github.run_id }}restore-keys: |osv-cache-continuwuity-renovate-osv-cache-maybe just
renovate-osv-cache?Only in buildkit, but as I already was updating GHA keys for architecture, it made sense to add a namespace at the same time.
I mean renovate isn't continuwuity code and is its own thing rather than tied to any of our actions
I can revert the file if you really want, it just didn't seem like a bad idea to namespace all cache keys as a general rule?
Yeah, but what I mean is it would make more sense to name space this under just renovate. 😅
Oh, I see... as they're already namespaced as renovate, that makes sense - I'll revert that one 😄
e6ee6e7a655d8b700826This is mainly another build optimisation attempt - the sccache action is doing good work, but I only see about 65% hitrate a lot of the time. I've noticed we're caching target build/binaries, so have dropped that out, but want to make sure we're caching the deps and incrementals without the clippy checks needing to upload a big 2GB cache each time 🥲
that all makes sense to me!
Caches should already be split by repository so we shouldn't run into any collisions, but I don't particularly see the harm. Renaming that docker cachr mount does make sense though if you are using it the same buildkit instance, because that isn't automatically namespaced.
Anyway, all good.
5d8b700826200ff35372200ff35372554c3c3a45554c3c3a458959ac06ac