Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Caching for cspell uses content caching strategy right now. This is good, but means hashing all files. We could investigate using the git-restore-mtime package. This will set mtime to the git history and could mean we can use the metadata cachings strategy. This *might* improve the runtimes even more.
https://stackoverflow.com/questions/2458042/restore-a-files-modification...
Quick testrun of impact of running git restore-mtime:
[32;1m$ git restore-mtime[0;m
18,163 files to be processed in work dir
Statistics:
0.22 seconds
18,421 log lines processed
50 commits evaluated
4,057 directories updated
18,163 files updated
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3464413
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
catchI think to do this we might want to install it on the docker images themselves to save the extra apt install step in each job.
eslint and stylelint have the same two cache strategy options so this would benefit all three if it's an improvement.
Comment #3
wim leersFascinating! 🤓
I have actually always wondered why this wasn't
git's default behavior. I've found it confusing in the past. Thanks for teaching me, @bbrala 😄Comment #4
bbralaComment #5
bbralaSince we now fixed the cache retrieval for all jobs we should try this. Cspell with cache is still 1.5 minutes.
Comment #6
bbralaTodo to validate, seems pretty straightforward,
apt update && apt install--y git-mtime && git mtime)Comment #7
bbralaNot gonna work if we use sparse checkouts, that means the minimum time is the 50th commit time. There might be ways around a full clone being slow by caching a sparse cron or something. But that seems like it's overkill.
There actually still might be merit to do this since it seems we do generate the cache every commit (push), so the state of the repo is kinda the same as the cache when the MR would run (cached on -50 commits, clones in MR at -50 commits, then merging changing and running linters).
Ok, think it might still be worth it.
Comment #10
bbralaWell, that didnt really have any results.
https://git.drupalcode.org/issue/drupal-3464413/-/pipelines/295506
vs
https://git.drupalcode.org/issue/drupal-3464413/-/pipelines/295507
All times are comparable for the lint runs. Nothing much to do there it seems. I changed to metadata and got all the things as artifacts, but it didnt really speed anything up. So unless i screwed up the changes, not worth it.
Comment #11
catchI think it might be at least good to keep the
timeon everything? It's useful to see the timings as much as possible.I hadn't realised we're only spending less than 10 seconds on each actual linting step, but yeah that means we probably need to look in the other 1m20s for savings