<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Rust - Tag - Roland's Dev Blog</title><link>https://rolandsdev.blog/tags/rust/</link><description>Rust - Tag - Roland's Dev Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sun, 09 Aug 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://rolandsdev.blog/tags/rust/" rel="self" type="application/rss+xml"/><item><title>Caching git clones across a slow network</title><link>https://rolandsdev.blog/posts/caching-git-clones-across-a-slow-network/</link><pubDate>Sun, 09 Aug 2026 10:00:00 +0800</pubDate><author><name>rolandjitsu</name><uri>https://github.com/rolandjitsu</uri><email>rolandjitsu@gmail.com</email></author><guid>https://rolandsdev.blog/posts/caching-git-clones-across-a-slow-network/</guid><description>&lt;p>If you run CI on cloud runners while your git server lives somewhere else - on-prem, another region, the far end of a slow VPN - you have probably watched a lot of time (and egress) disappear into cloning the same repositories over and over.&lt;/p>
&lt;p>The setup I kept running into: an on-prem GitLab, an elastic fleet of runners autoscaling in the cloud, and a handful of repos in the tens of gigabytes. Multiply that by hundreds or thousands of jobs a day and every single one does a fresh clone across the WAN. The link is the bottleneck, the egress is not free, and the runners end up spending more time fetching code than running it.&lt;/p></description></item></channel></rss>