- Issue created by @bbrala
- 🇬🇧United Kingdom catch
I 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.
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Fascinating! 🤓
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 😄 - 🇳🇱Netherlands bbrala Netherlands
Since we now fixed the cache retrieval for all jobs we should try this. Cspell with cache is still 1.5 minutes.
- 🇳🇱Netherlands bbrala Netherlands
Todo to validate, seems pretty straightforward,
- Add package to warm cache and lint jobs
- Adjust warm cache job to always run
- have lint jobs depend on that job and get the cache artifacts, double check they use metadata instead of file contents, that is either commandline argument or config change.
- Validate runtime against HEAD (minus the (pseudocode)
apt update && apt install--y git-mtime && git mtime) - Decide if we want it
- If so, add package to images
- Adjust cache and lint jobs to run the mtime fix
- 🇳🇱Netherlands bbrala Netherlands
Not 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.
- Merge request !9671feat: try and use git restore-mtime to speed up linting, works locally. cpell... → (Open) created by bbrala
- 🇳🇱Netherlands bbrala Netherlands
Well, 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.
- 🇬🇧United Kingdom catch
I 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, while that means we probably need to look in the other 1m20s for savings
