ci: use caching #440
ci: use caching #440
Conversation
|
@tomdracz doesn't seem to have any real impact, which doesn't surprise me - feel free to trigger a re-run to check if follow-up runs are any better |
|
Yeah, might not bring much improvement. I've been playing with generator specs here #441 and fair bit of time is spent on installing and fetching all the packages https://github.com/shakacode/shakapacker/actions/runs/8213456703/job/22464895242#step:6:293 ... but fair few of them we already install in setup step so I wondered if pointing at some shared bundler cache would help here. Granted, might be that some of this slowness is on Ruby itself as for example 3.1 ones are much better https://github.com/shakacode/shakapacker/actions/runs/8213456703/job/22464896090?pr=441#step:6:298 it's just Truth be told those specs will be slow as we ran through multiple package managers so maybe it is what it is. #430 should remove at least bits of it which is always a win |
|
Yup that matches what I expect - and to be fair, it's not that slow all things considered; having cancellation helps, and really |
|
btw I'm happy to drop Ruby 2.7 support if you want 🤷 |
|
Right, with other improvements, there's probably limited value of caching here, let's drop this PR @G-Rath |
Summary
This attempts to use caching to speed up the dummy and generator workflows - it's hard to completely cache everything since we're testing against so many package managers within the specs themselves, but it should be easy to at least try caching
npmandyarndownloads which'll hopefully give some speed up.Pull Request checklist
Add/update test to cover these changesUpdate documentationUpdate CHANGELOG file