Christian Winther

@renchap need to figure out how to run the pipeline in my fork this weekend, I ended up caching some webpack and sprockets data as well, for the heck of...

yep, this is exactly what I'm thinking - trying that out now :)

At $DayJob we just configured remote buildx connections for each architecture, so buildx in CI job would coordinate build steps across two native CPU architectures remotely - but it doesn't...

Honestly, the best way to solve the slow speeds is to either pick a CI provider that provide native arm64/amd64 or increase the GitHub runner size to get increased number...

More CPU will absolutely help to some degree, the two cores provided by basic runners, combined with webpack, sprockets, qemu and other stuff running is pretty tight, especially considering builkit...

Hetzner is a great choice for this - didn't know they had ARM runners hosts now :) re buildx, yes, basically that - there is some details on it here...

The layer caching works reasonably well (without mount caching) - a NOOP commit ran end-to-end in 11s on GitHub runners https://github.com/jippi/mastodon/actions/runs/5494777769/jobs/10013761774

> Asset compilation (at least the webpack/webpacker part) is using Webpacker 4, and should scale along the number of cores. If this is not the case, then we may have...

can't reproduce :(

:+1: