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
We clear the composer cache when we build the CLI container, but this is a lost opportunity. Most of the packages we use are fixed since our versions don't change often, so leaving the composer cache in place means subsequent builds downstream could speed up a lot by not needing to download all the sources - and we have a lot of sources. I propose we leave the composer cache in place here.
Something to be aware of is the main impact is on PaaS currently, but improvements in the way SaaS works may more and more require composer install, in order to follow mainstream best practices.
An alternative approach is to use gitlab CI cache, which might look like this (internal ref GOVCMS-3110).
Composer cache is 81M. So adding a layer in docker with 81MB is not great, although it would only be in Dockerfile.cli.
The alternative currently is downloading 230 packages in every gitlab job. Sometimes twice.
We clear the composer cache when we build the CLI container, but this is a lost opportunity. Most of the packages we use are fixed since our versions don't change often, so leaving the composer cache in place means subsequent builds downstream could speed up a lot by not needing to download all the sources - and we have a lot of sources. I propose we leave the composer cache in place here.
Something to be aware of is the main impact is on PaaS currently, but improvements in the way SaaS works may more and more require
composer install
, in order to follow mainstream best practices.An alternative approach is to use gitlab CI cache, which might look like this (internal ref GOVCMS-3110).
The text was updated successfully, but these errors were encountered: