CI pipeline's build jobs should cache Composer data

This has kinda been discussed in the gitlab_templates queue. https://www.drupal.org/project/infrastructure/issues/3445532 🐛 Random HTTP timeouts for GitLab CI jobs Active

Few points - the main thing is we only need to cache the internal Composer cache, not anything from the built project.

Since this only affects internal infrastructure, it can be committed to both 1.x and 1.0.x after launch.

phenaproxima → closed merge request !147

Had a few more thoughts here. What do you think?

Eurgh...the more I think about this, the more I think we need a proper dependency-locking strategy (or lack thereof) to take advantage of this feature. Self-assigning to reason this out a bit more.

I don't think the MR will result in any caching between pipelines.

If the cache (or vendor, or both) dir is stored as an artifact, only from branch runs, and pulled down before composer commands are run in all pipelines, then composer update will deal with any staleness. Then the results of that are used for the other jobs. This might work but you need to manually pull down the artifact from the gitlab API.

We are using this pattern for phpstan et al caches in core, but it was very hard to get right and also those are individual files and not a directory. For example a lot of these caches are based on absolute directory paths and they are different every build. Pretty sure ci_project_dir is not the same for every MR. And build dirs are different depending on whether you have commit access to the repo or not, even for different pipelines on the same MR.

This is the core issue that originally added caching, there have been lots of changes since then though (because the original MR didn't actually work unless you were a core committer due to absolute paths), so easier to review the gitlab yaml in HEAD. 📌 Try to store the phpstan result cache as an artifact Active But as above we didn't try to cache anything that's a directory yet.