Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ccache: Cache is not building/restoring/saving #880

Open
Gadgetoid opened this issue Dec 3, 2024 · 7 comments
Open

ccache: Cache is not building/restoring/saving #880

Gadgetoid opened this issue Dec 3, 2024 · 7 comments

Comments

@Gadgetoid
Copy link
Contributor

I've been debugging loooooong CMake build times on pimoroni-pico with ccache being the culprit. I remembered I probably inherited the ccache code from here, so when I figure out how to fix it, should probably fix it here too!

Check any action with ccache and you'll see a cache miss, and a fail to upload the resulting cache, it looks like ccache has changed to not use /home/runner/.ccache (~/.cache) by default anymore.

@Gadgetoid
Copy link
Contributor Author

On non-Windows systems, the default is $HOME/.ccache if such a directory exists

if such a directory exists

🤔 we have a good ol' fashioned paradox.

@Daft-Freak
Copy link
Collaborator

Maybe we should set CCACHE_DIR explicitly like the mac build does... though it seems that one isn't working either.

@Daft-Freak
Copy link
Collaborator

Wow, you can really see when this stopped working:
Screenshot 2024-12-03 at 12-26-31 CMake · Workflow runs · 32blit_32blit-sdk

... without any actions changes... using a supposedly stable 2 year old OS version... sigh

@Gadgetoid
Copy link
Contributor Author

Yeah you're not wrong- in pimoroni-pico it's taking >20min 💀 up from ~4min.

And it didn't occur to me that this should not happen 😬

I'm trying mkdir -p /home/runner/.ccache on a prayer the docs aren't lying to me.

@Gadgetoid
Copy link
Contributor Author

Well that worked (and is extremely cursed!)

pimoroni/pimoroni-pico@9290243

@Gadgetoid
Copy link
Contributor Author

My best sleuthing suggests that this change happened with ccache 4.0 on 2020-10-18.

I think we might have been riding on having an existing cache - which implicitly created the directory when restored - for much longer. It wouldn't break until cache misses started landing, and all branches get access to the default branch cache so that could have taken some time (long enough between main builds for the cache to expire?). That's my best theory for "why stable not stable" anyway.

@Daft-Freak
Copy link
Collaborator

Daft-Freak commented Dec 3, 2024

This also seems to work: 9d6adb3

Relying on a fallback was probably always a bad idea, it's just weird that it suddenly broke now...

EDIT: It looks like your theory is correct though, the first build where this happened did fail to find an existing cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants