You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ability to swap out actions/cache for the faster alternative buildjet/cache
Background/problem
GitHub Actions cache has a number of issues surrounding performance when used on self-hosted runners. GitHub has failed to address this on numerous occassions so BuildJet created their own free cache alternative with double the amount of storage and much faster performance. It would be nice if we could use this in ramsey/composer-install, providing an option to specify which cache we wanted to use.
Proposal/solution
I propose that we add a new option which specifies which cache we would like to use and have this shared action then use the cache specified. We can leave the default to GitHub to keep backward compatibility.
I don't know anything about BuildJet, and I hesitate to add additional cache providers, since that will increase the complexity and maintenance burden for this action. It also looks like BuildJet is an additional third-party paid service, and while I don't have anything against them for that, it means this change is likely to benefit only a small set of users.
With that said, you should be able to fork ramsey/composer-install and swap actions/cache@v3 for buildjet/cache@v3 in ./action.yml, and that should be all you need to get this running with their caching provider.
Ability to swap out actions/cache for the faster alternative buildjet/cache
Background/problem
GitHub Actions cache has a number of issues surrounding performance when used on self-hosted runners. GitHub has failed to address this on numerous occassions so BuildJet created their own free cache alternative with double the amount of storage and much faster performance. It would be nice if we could use this in
ramsey/composer-install
, providing an option to specify which cache we wanted to use.Proposal/solution
I propose that we add a new option which specifies which cache we would like to use and have this shared action then use the cache specified. We can leave the default to GitHub to keep backward compatibility.
Alternatives
Haven't considered any alternatives.
Additional context
https://buildjet.com/for-github-actions/blog/launch-buildjet-cache
The text was updated successfully, but these errors were encountered: