<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Ci on My personal blog</title>
		<link>https://jens.dev/tags/ci.html</link>
		<description>Recent content in Ci on My personal blog</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Tue, 30 Jun 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://jens.dev/tags/ci/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Splitting Rust builds and tests on Codeberg</title>
				<link>https://jens.dev/2026/06/30/splitting-rust-builds-and-tests-on-codeberg.html</link>
				<pubDate>Tue, 30 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://jens.dev/2026/06/30/splitting-rust-builds-and-tests-on-codeberg.html</guid>
				<description>&lt;p&gt;After I got &lt;a href=&#34;https://jens.dev/2026/03/15/building-containers-on-codeberg.html&#34;&gt;building containers on Codeberg&lt;/a&gt; sorted out, the next thing that broke on me was much more boring on paper: the test job kept getting killed.&lt;/p&gt;&#xA;&lt;p&gt;Not failing. Killed.&lt;/p&gt;&#xA;&lt;p&gt;The logs would scroll happily through compilation and a few dozen passing tests, and then the runner would just cut the job off mid-run with a deadline error.&lt;/p&gt;&#xA;&lt;p&gt;So this post is about that: what to do when your Rust test suite is simply too slow to fit inside a single hosted CI job, and the runner has opinions about how long it will wait for you.&lt;/p&gt;</description>
			</item>
			<item>
				<title>When Let&#39;s Encrypt Is Valid but GitHub Actions Still Rejects It</title>
				<link>https://jens.dev/2026/06/10/letsencrypt-gen-y.html</link>
				<pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://jens.dev/2026/06/10/letsencrypt-gen-y.html</guid>
				<description>&lt;p&gt;A few days ago I ran into a surprisingly tricky TLS issue while setting up automated tests for a service running behind Let&amp;rsquo;s Encrypt certificates.&lt;/p&gt;&#xA;&lt;p&gt;The symptoms were confusing at first:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Browsers accepted the certificate.&lt;/li&gt;&#xA;&lt;li&gt;&lt;code&gt;curl --insecure&lt;/code&gt; worked.&lt;/li&gt;&#xA;&lt;li&gt;The certificate looked perfectly valid.&lt;/li&gt;&#xA;&lt;li&gt;Yet GitHub Actions consistently failed with:&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#272822;background-color:#fafafa;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;SSL certificate problem: unable to get local issuer certificate&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;At first glance this looked like a classic missing intermediate certificate problem.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Building containers on Codeberg</title>
				<link>https://jens.dev/2026/03/15/building-containers-on-codeberg.html</link>
				<pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://jens.dev/2026/03/15/building-containers-on-codeberg.html</guid>
				<description>&lt;p&gt;I have been moving more and more of my smaller projects over to Codeberg lately.&lt;/p&gt;&#xA;&lt;p&gt;For plain git hosting and Forgejo based CI, it is a very pleasant setup. The one area where I had to do a bit more work than expected was container builds.&lt;/p&gt;&#xA;&lt;p&gt;At first glance this looks like it should be boring:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;write a &lt;code&gt;Dockerfile&lt;/code&gt;&lt;/li&gt;&#xA;&lt;li&gt;add a CI step&lt;/li&gt;&#xA;&lt;li&gt;build the image&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;But on a hosted Codeberg runner this is exactly the type of thing where the defaults are not quite the defaults you may be used to from GitHub Actions or from your own machine.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Letting an LLM Review Our Pull Requests (So You Don’t Have To)</title>
				<link>https://jens.dev/2025/08/08/pr-reviews.html</link>
				<pubDate>Fri, 08 Aug 2025 00:00:00 +0000</pubDate>
				<guid>https://jens.dev/2025/08/08/pr-reviews.html</guid>
				<description>&lt;blockquote&gt;&#xA;&lt;p&gt;This post is a cross-post from &lt;a href=&#34;https://downtozero.cloud/&#34;&gt;Down to Zero&lt;/a&gt;. Canonical source: &lt;a href=&#34;https://downtozero.cloud/posts/2025/pr-reviews/&#34;&gt;https://downtozero.cloud/posts/2025/pr-reviews/&lt;/a&gt;&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;We love automation. We use it to power our infrastructure, to scale workloads down to zero, and—increasingly—to shrink the amount of human attention needed to ship high-quality code. One place that still felt stubbornly manual was &lt;strong&gt;pull-request reviews&lt;/strong&gt;. Between Cursor as our IDE, ChatGPT/Codex for prototyping, and &lt;code&gt;gemini-cli&lt;/code&gt; for quick checks, our local workflows were fast—but CI still waited for a human.&lt;/p&gt;</description>
			</item>
			<item>
				<title>A Solar Powered GitHub Runner</title>
				<link>https://jens.dev/2023/04/15/solar-powered-github-runner.html</link>
				<pubDate>Sat, 15 Apr 2023 09:08:05 +0000</pubDate>
				<guid>https://jens.dev/2023/04/15/solar-powered-github-runner.html</guid>
				<description>&lt;p&gt;&lt;a href=&#34;https://downtozero.cloud/posts/assets/2023/solar-powered-github-runner/&#34;&gt;This is a cross-posting from downtozero.cloud&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;The more our little project progresses, the more code we produce. And like most of our community these days, we host our code on GitHub.&lt;/p&gt;&#xA;&lt;p&gt;So during development we discussed the implications of a DownToZero architecture for something like a GitHub process. We quickly identified two types of actions that need to be performed on the infrastructure.&lt;/p&gt;&#xA;&lt;p&gt;The first is the CI build, which should always provide immediate feedback to the developer. It checks for compliance as well as code integrity and is usually deeply involved in the development process. These jobs are time-sensitive because someone is usually waiting for them.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
