Clearing composer cache creates a lot of work downstream

[simesy]

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).

cache:
  key: "$CI_PROJECT_PATH_SLUG"
  paths:
    - /home/.composer/cache

[simesy]

I looked at approaching this in paas scaffold, but it's mostly the first composer install we want to avoid, as after that we mostly COPY /app

[simesy]

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.

[jackwrfuller]

@simesy is this issue still prevalent?