Astro build cache not saving/restoring
Hi hi hello :)
I host a personal image gallery built with Astro on Pages, which naturally contains a bunch of images that get optimized into a few different variants during the build stage, using the built-in
getImage utility. Astro caches these files in the node_modules/.astro/assets directory so subsequent builds don't need to re-optimize everything from scratch.
Pages is supposed to upload and restore the node_modules/.astro directory as long as build caching is enabled, you're using v2, etc. and also if it detects "astro" as a dependency (or something like that). However, in my case, it is not doing this, resulting in build times of ~17 minutes every time.
There is another ticket from late last year about this problem but it seems to be a separate issue: https://discord.com/channels/595317990191398933/114720987077333003043 Replies
I have confirmed that the images are properly being saved to the Astro cache directory by changing the build command:
So despite them being saved to the astro cache dir, they aren't being saved between builds. The pages buildbot does not say which or how many files it's caching, it only says the following after the build completes:
...which isn't very helpful, so I can't tell if they are not being uploaded in the first place, or if they are being uploaded but not downloaded correctly. I should note that the caching does work locally on two computers and my VPS, so I don't think it's an Astro thing as far as I can tell. e.g. building locally with the cache takes only 8 seconds vs 17 minutes without the cache.
I do have full build logs available that I can send via DM, as well as any other info/files that might help debug. But I am just curious if there's anything I'm missing, because Pages build cache for Astro projects has certainly worked for me before. Thanks in advance!
Is it rude to bump a thread? 😭 lol
Hey. Can you please share the logs and deployment ID?
?pages-deployment-id
The Pages deployment ID is a unique build identifier.
It's the UUID in the browser bar (for example, a URL would be
dash.cloudflare.com/ACCOUNT_ID/pages/view/PROJECT/DEPLOYMENT_ID where the deployment ID looks something like a398d794-7322-4c97-96d9-40b5140a8d9b).
This ID can help troubleshoot some issues with Pages builds so if you have a failing build make sure you grab that ID for the team to use.Ah sorry I didn't get the notif for this, here is the deployment ID of a build where I am calling
ls -lhR node_modules/.astro after the build step (the directory that is supposed to be cached):
ebd18526-afcf-40f6-904a-88d69779028b
I hope you can see the logs in there, otherwise I can DM them to youI've just escalated your issue. A support engineer will look into it
Hello @Vero 🐙 do we have an internal ticket ID for this case? If so, can you DM me that?
No, we don't
Hello @cowslaw, can you please DM me the ticket ID from late last year about this?
I linked to the Discord thread above, but it wasn’t my ticket so I don’t have the ID for you
We're rolling out some debugging right now @cowslaw
You still seeing the issue?
I last deployed on the 11th and it was still not working, gonna try again right now! Will I just be able to see what files it’s caching?
aahh guessing it's not out just yet? Output still looks the same and it hasn't cached anything
they're internal debug logs so you won't see them but yeah not fully out yet, I'll ask you to run a new build when they are 🙂
cc: @Dario who is doing the rollout
ah gotcha
I was able to repro this issue using a fresh astro project in case you guys needed some extra info too: https://github.com/zaknesler/cloudflare-astro-assets
GitHub
GitHub - zaknesler/cloudflare-astro-assets: Demo of Astro assets no...
Demo of Astro assets not being saved/restored using Cloudflare Pages. - zaknesler/cloudflare-astro-assets
But I will be here to retry deployments, no problem at all
@cowslaw this is now fully rolled out if you can retry
sweet, it'll finish in a minute but here is the deployment ID:
818f110e-d83b-4c12-bf3a-7b93b3c5fc80Ok debug logs gave us more info
Essentially, it comes down to this line:
WARN Ignoring not compatible lockfile at /opt/buildhome/repo/pnpm-lock.yamlpnpm is then very likely changing the lockfile to be compatible with the version installed (8.7.1) and because we key on the lockfile, it's chaning the cache key From https://github.com/zaknesler/cloudflare-astro-assets/blob/main/pnpm-lock.yaml seems like it was made with pnpm v9
y'know deep down I felt it was pnpm related
but 8.7.1 is in use
just pushed with 8.7.1 gonna try that
95e7ce3b-7fc5-4de8-ac3b-f15067c0ebbd lol that worked, the deployment finished before I could copy and paste the uuidnice! 😃 🚀
ok well I'm swearing off of pnpm
@Walshy | Deploying idea! maybe we should add a (public) warning to the logs, if you're opted in for the build caching and the lock file is not recognized we could clearly log that this will make caching not work, WDYT?
haha glad it's resolved and glad we have more info here now -- this is the first case we've needed to actually debug build caching so far
the issue is we didn't know pnpm would ignore this, we just saw the lockfile and was like "oh yay"
but maybe we should have a warning if the hash changes in the build
maybe.... I guess I don't know what the behavior is with all the various PMs, if all just override the lockfile in case it's invalid then I think a warning there makes more sense (+ a warning when the lock file is not present at all of course)
yarn definitely overrides, npm overrides as well afaik
no idea about bun
ok other idea....
kinda combining both....
we can check the hash before and after the install command right? and use that as an indication that the install has overridden the lock file 🤔
yep, my thought was put it at the end just so it's seen - logs are noisy no one looks at the middle :LuL:
but i'm not suepr fussed about it, just that's where my head goes to
ah I see makes sense 🙂
yes! 😅
wonder if it's worth exposing the cache key as well
and documenting how it's generated
so people can self-debug
Well I'm just gonna go back to npm or use bun instead, thank you both so much for helping me out
hnnng it went from 17 minutes to less than 2 mins, and most of that is pulling from LFS, I am so happy now lol
no problem! 🫶 sorry it took a while 🙂
all good!
Theoretically I could set PNPM_VERSION to whichever version I am using locally and the lockfiles should match, right?
based on https://developers.cloudflare.com/pages/configuration/language-support-and-tools#supported-languages-and-tools
yes 🙂
definitely
or use the packageManager package.json field
right!
Yeah I just had a build error with the installed bun version (1.0.1) that needed the latest version (1.1.20) and I used BUN_VERSION for that. I like the packageManager field better though, ty
no problem 😄
I am not sure.... I feel like we might want to keep this internal only so that we can change the logic under the hood if need be without potentially disrupting users? 🤔 (e.g. if someone was relying on that for some reason 🤷♂️)
why would we disrupt users by just exposing it?
how would someone rely on it? it's just a log, it isn't something you can ask for
no idea 😅 , sorry what I was trying to say is more regarding your second point, about telling people how the cache key is computed....
someone could hack around and save restore lock files or som.... yeah doesn't make a lot of sense now does it? 😅
ah yeah i think it's fine, if someone hacks the lockfile to have the same hash so be it, it's their build but that'd be like 0.0001% of users :LuL:
yeah you're right...