I did some testing in my fork and here's what I found.
When the restore-keys are removed as suggested in the article, the cache size is cut by roughly 40%. The last successful build in `trunk` showed the cache was ~119MB, my PR (with no prior caching) shows ~73MB.
I think this is a big thumbs up change.
Next I did some testing switching out npx install-changed with npm ci.
For the JavaScript coding standards job:
Using npx install-changed
| Step | Time
|
|---|
| Install dependencies | 54s
|
| Run JSHint | 9s
|
Using npm ci
| Step | Time
|
|---|
| Install dependencies | 26s
|
| Run JSHint | 28s
|
For the E2E testing job
Using npx install-changed
| Step | Time
|
|---|
| Install dependencies | 1m 17s
|
| Build WordPress | 1m 34s
|
Using npm ci
| Step | Time
|
|---|
| Install dependencies | 37s
|
| Build WordPress | 1m 48s
|
I was trying to recall my reasoning for using npx install-changed --install-command="npm ci" instead of just npm ci. When switching the two out, it seems that npm ci is slightly faster. But, it is a bit misleading to only look at the "Install Dependencies" steps because time shifts between two of the steps.
When Grunt related tasks are run for the first time, install-changed is run to check for the packagehash.txt file, and if one is not present (or the hashes do not match), npm install is run again. By running install changed in the first step, it prevents install from running twice (even if partially).
I don't feel strongly either way on this switch.