[ci] make use of composer install cache to make parallel jobs faster

[TomasVotruba]

No description provided.

[mollux]

@TomasVotruba this makes sense.

I retriggered the CI pipeline to see the effect

[TomasVotruba]

Thanks 👍

I've checked the CI jobs on my PR and they were extreemely long. I thought it's the databse, but the composer was taking 1-2 minutes in most cases.

I use this Github action everywhere for past 5 years.
It solves composer caching in the best way possible, in the background and for us 👍

[TomasVotruba]

Good to go ✔️

[mollux]

@TomasVotruba

can you elaborate on extremely long CI jobs?
I see this PR as a valuable improvement, but the impact is not that

as the caching merely removed 10 - 20 seconds

before / first run

after / cached run

[TomasVotruba]

The 1 m 22 seconds is way too much for composer install, even for 248 packages. I think the caching might kick-in later, as 1st run has to trigger it.

To compare, Rector has 93 packages to install - https://github.com/rectorphp/rector-src/actions/runs/6085162917/job/16508611947, including patching +10 files

It's done in 13 seconds.

I'll check for the bottleneck further, to keep scope of this PR narrow and easy to merge 👍

[mollux]

@TomasVotruba

the cache is active, see screenshot of the run and the cache.

But still a no-brainer improvement! 🥳

[TomasVotruba]

Exactly 😆

[mollux]

@TomasVotruba
be aware that there are some extra tasks executed in the Composer post install event, see post-install-cmd.
That may be the main reason of the longer time, as e.g. assets need to be compiled.

I was just looking to the capabilities of the that github Action, to check if it could also run the composer validate.
But we have another task / test that does that + vallidation if the composer.lock file fully corresponds with the changes in composer.json

so good to go!

[escopecz]

Great idea! 💡

[TomasVotruba]

Thanks for quick merge 🥳

[staabm]

fyi, I did some measuring with rector on the mautic code-base and found some low hanging fruits.

• Reduce excessive regex use rectorphp/rector-src#4950
• Implement a max jobs per worker budget rectorphp/rector-src#4965
• UseImportsTraverser: don't deep traverse rectorphp/rector-src#4994

memory wise you should now be able to run rector without a ever climbing RAM usage (not yet released)