Skip to content

Commit 64feb3f

Browse files
hspakhspak
committed
feat: new post
1 parent 392659e commit 64feb3f

File tree

4 files changed

+170
-0
lines changed

4 files changed

+170
-0
lines changed

‎docs/feed.xml

+44
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,50 @@
77
<name>Hong Shick Pak</name>
88
</author>
99
<id>https://hspak.dev/atom.xml</id><entry>
10+
<title>Why is CI so slow?</title>
11+
<published>Oct 26, 2024</published>
12+
<updated>Oct 26, 2024</updated>
13+
<link href="https://hspak.dev/post/why-is-ci-slow/" type="text/html"/>
14+
<id>https://hspak.dev/post/why-is-ci-slow/</id>
15+
<content type="html">
16+
&lt;p&gt;I believe that containerized CI environments helped the industry move forward.
17+
We have easily reproducable environments for testing and allows companies to
18+
stay relatively platform agnostic. But they're often reeeally slow. It's sad
19+
that most CI improvements have been thanks to tools like &lt;a href=&quot;https://bun.sh/&quot;&gt;bun&lt;/a&gt; or
20+
&lt;a href=&quot;https://astral.sh/blog/uv&quot;&gt;uv&lt;/a&gt; re-thinking package management from the ground
21+
up with performance at the forefront.&lt;/p&gt;
22+
&lt;p&gt;Most CI platforms &lt;a href=&quot;https://circleci.com/&quot;&gt;are&lt;/a&gt;
23+
&lt;a href=&quot;https://github.com/features/actions&quot;&gt;all&lt;/a&gt;
24+
&lt;a href=&quot;https://docs.gitlab.com/runner/&quot;&gt;the&lt;/a&gt; &lt;a href=&quot;https://buildkite.com/&quot;&gt;same&lt;/a&gt;: you
25+
define some YAML-esque file a DAG of containers that run some shell scripts.
26+
These CI platforms can easily run multi-tenant workloads and improve margins
27+
since these container executions are mostly ephemeral. Artifacts are usually
28+
pushed out to an object store like &lt;a href=&quot;https://aws.amazon.com/s3/&quot;&gt;AWS S3&lt;/a&gt;. Most of
29+
them offer a &amp;quot;cache&amp;quot; where they can push and pull from an object store. This is
30+
not really a cache. It's a hack at an attempt to mimic what a cache on local dev
31+
looks like.&lt;/p&gt;
32+
&lt;p&gt;So much of CI time is burned:&lt;/p&gt;
33+
&lt;ul&gt;
34+
&lt;li&gt;Downloading a container, which is often massive to include all necessary tooling.&lt;/li&gt;
35+
&lt;li&gt;Installing dependencies of your project, which is also often also slow.&lt;/li&gt;
36+
&lt;/ul&gt;
37+
&lt;p&gt;I wonder why there has not been an attempt (a successful attempt?) of creating a
38+
CI platform that mimics local development environment:&lt;/p&gt;
39+
&lt;ul&gt;
40+
&lt;li&gt;The git repo is &amp;quot;hot&amp;quot;. It'll have the last commit checked out, which will never be that far away from the origin server.
41+
Pulling down the next branch to test should be small incremenatal delta.&lt;/li&gt;
42+
&lt;li&gt;The filesystem persists: the dependencies are already mostly there (mod new changes).
43+
Any cached files generated during builds and tests persist.
44+
There's no slow fetches from an object store.&lt;/li&gt;
45+
&lt;/ul&gt;
46+
&lt;p&gt;Of course, a persistent fs allows for bugs to creep up (stale cache not being
47+
invalidated, invalid state not cleaned up, etc.). But this should be the
48+
exception we face, not the default. No developer is blowing their environment
49+
away on every commit. CI shouldn't have to either.&lt;/p&gt;
50+
&lt;p&gt;Food for thought.&lt;/p&gt;
51+
</content>
52+
</entry>
53+
<entry>
1054
<title>What if I'm Wrong</title>
1155
<published>December 28, 2022</published>
1256
<updated>December 28, 2022</updated>

‎docs/index.html

+9
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,15 @@
2727
<div class="indexBlock"><a href="https://hspak.com/">By Hong</a></div>
2828
</div>
2929
</div>
30+
<div class="block">
31+
<div class="entry">
32+
<a href="/post/why-is-ci-slow/">
33+
<h2>Why is CI so slow?</h2>
34+
<div class="date">Oct 26, 2024</div>
35+
<div class="preview">Containerized CI runs regressed a bit in terms of cache. Can we not get CI as fast as local?</div>
36+
</a>
37+
</div>
38+
</div>
3039
<div class="block">
3140
<div class="entry">
3241
<a href="/post/what-if-im-wrong/">

‎docs/post/why-is-ci-slow/index.html

+75
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
<!doctype html>
2+
<html>
3+
<head>
4+
<title>Why is CI so slow?</title>
5+
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
6+
<meta http-equiv="Content-Security-Policy" content="default-src 'self';">
7+
<meta name="referrer" content="strict-origin">
8+
<meta name="author" content="Hong Shick Pak">
9+
<meta name="viewport" content="width=device-width, initial-scale=1">
10+
<meta name="keywords" content="Michael Pak, Hong Shick Pak, Hong, Shick, Pak, Michael, Blog, hspak">
11+
<meta name="description" content="Blog of Hong Shick Pak">
12+
<meta property="og:url" content="https://hspak.dev">
13+
<meta property="og:type" content="website">
14+
<meta property="og:site_name" content="Hspak">
15+
<meta property="og:title" content="Hspak">
16+
<meta property="og:description" content="Blog of Hong Shick Pak">
17+
<meta property="twitter:creator" content="@hspasta">
18+
<link rel="canonical" href="https://hspak.dev/">
19+
<link rel="stylesheet" href="/index.css">
20+
</head>
21+
<body>
22+
<div class="outer">
23+
<div class="container">
24+
<div class="block">
25+
<a href="/"><h1>Blog</h1></a>
26+
</div>
27+
<div class="block">
28+
<h2>Why is CI so slow?</h2>
29+
<div class="date">Oct 26, 2024 </div>
30+
<div class="body">
31+
<p>I believe that containerized CI environments helped the industry move forward.
32+
We have easily reproducable environments for testing and allows companies to
33+
stay relatively platform agnostic. But they're often reeeally slow. It's sad
34+
that most CI improvements have been thanks to tools like <a href="https://bun.sh/">bun</a> or
35+
<a href="https://astral.sh/blog/uv">uv</a> re-thinking package management from the ground
36+
up with performance at the forefront.</p>
37+
<p>Most CI platforms <a href="https://circleci.com/">are</a>
38+
<a href="https://github.com/features/actions">all</a>
39+
<a href="https://docs.gitlab.com/runner/">the</a> <a href="https://buildkite.com/">same</a>: you
40+
define some YAML-esque file a DAG of containers that run some shell scripts.
41+
These CI platforms can easily run multi-tenant workloads and improve margins
42+
since these container executions are mostly ephemeral. Artifacts are usually
43+
pushed out to an object store like <a href="https://aws.amazon.com/s3/">AWS S3</a>. Most of
44+
them offer a &quot;cache&quot; where they can push and pull from an object store. This is
45+
not really a cache. It's a hack at an attempt to mimic what a cache on local dev
46+
looks like.</p>
47+
<p>So much of CI time is burned:</p>
48+
<ul>
49+
<li>Downloading a container, which is often massive to include all necessary tooling.</li>
50+
<li>Installing dependencies of your project, which is also often also slow.</li>
51+
</ul>
52+
<p>I wonder why there has not been an attempt (a successful attempt?) of creating a
53+
CI platform that mimics local development environment:</p>
54+
<ul>
55+
<li>The git repo is &quot;hot&quot;. It'll have the last commit checked out, which will never be that far away from the origin server.
56+
Pulling down the next branch to test should be small incremenatal delta.</li>
57+
<li>The filesystem persists: the dependencies are already mostly there (mod new changes).
58+
Any cached files generated during builds and tests persist.
59+
There's no slow fetches from an object store.</li>
60+
</ul>
61+
<p>Of course, a persistent fs allows for bugs to creep up (stale cache not being
62+
invalidated, invalid state not cleaned up, etc.). But this should be the
63+
exception we face, not the default. No developer is blowing their environment
64+
away on every commit. CI shouldn't have to either.</p>
65+
<p>Food for thought.</p>
66+
</div>
67+
</div> <div class="block">
68+
<div class="footer">
69+
<a href="#top">To Top</a> · <a href="https://hspak.com">By Hong</a>
70+
</div>
71+
</div>
72+
</div>
73+
</div>
74+
</body>
75+
</html>

‎posts/0007-why-is-ci-so-slow.md

+42
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
Name: why-is-ci-slow
2+
Title: Why is CI so slow?
3+
Description: Containerized CI runs regressed a bit in terms of cache. Can we not get CI as fast as local?
4+
Draft: false
5+
Publish Date: Oct 26, 2024
6+
---
7+
I believe that containerized CI environments helped the industry move forward.
8+
We have easily reproducable environments for testing and allows companies to
9+
stay relatively platform agnostic. But they're often reeeally slow. It's sad
10+
that most CI improvements have been thanks to tools like [bun](https://bun.sh/) or
11+
[uv](https://astral.sh/blog/uv) re-thinking package management from the ground
12+
up with performance at the forefront.
13+
14+
Most CI platforms [are](https://circleci.com/)
15+
[all](https://github.com/features/actions)
16+
[the](https://docs.gitlab.com/runner/) [same](https://buildkite.com/): you
17+
define some YAML-esque file a DAG of containers that run some shell scripts.
18+
These CI platforms can easily run multi-tenant workloads and improve margins
19+
since these container executions are mostly ephemeral. Artifacts are usually
20+
pushed out to an object store like [AWS S3](https://aws.amazon.com/s3/). Most of
21+
them offer a "cache" where they can push and pull from an object store. This is
22+
not really a cache. It's a hack at an attempt to mimic what a cache on local dev
23+
looks like.
24+
25+
So much of CI time is burned:
26+
- Downloading a container, which is often massive to include all necessary tooling.
27+
- Installing dependencies of your project, which is also often also slow.
28+
29+
I wonder why there has not been an attempt (a successful attempt?) of creating a
30+
CI platform that mimics local development environment:
31+
- The git repo is "hot". It'll have the last commit checked out, which will never be that far away from the origin server.
32+
Pulling down the next branch to test should be small incremenatal delta.
33+
- The filesystem persists: the dependencies are already mostly there (mod new changes).
34+
Any cached files generated during builds and tests persist.
35+
There's no slow fetches from an object store.
36+
37+
Of course, a persistent fs allows for bugs to creep up (stale cache not being
38+
invalidated, invalid state not cleaned up, etc.). But this should be the
39+
exception we face, not the default. No developer is blowing their environment
40+
away on every commit. CI shouldn't have to either.
41+
42+
Food for thought.

0 commit comments

Comments
 (0)