<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>GitLab on Tom Meurs</title>
    <link>https://tommeurs.nl/en/tags/gitlab/</link>
    <description>Recent content in GitLab on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Tue, 29 Sep 2026 09:00:00 +0200</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/tags/gitlab/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Supply Chain Security in GitLab CI: SBOM, cosign, and the Policy That Blocks</title>
      <link>https://tommeurs.nl/en/posts/supply-chain-security-gitlab-ci/</link>
      <pubDate>Tue, 29 Sep 2026 09:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/supply-chain-security-gitlab-ci/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; A pipeline that scans images and writes an SBOM, with nothing checking either at admission, had been green for a year and had stopped nothing. Four steps below: an SBOM Trivy can read back, a cosign signature on the digest with the key in Vault, the SBOM attached as an attestation, and a Kyverno policy that refuses the rest. Then a table of which SLSA Build L3 requirements a self-hosted GitLab runner meets, and the two it doesn&amp;rsquo;t.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Container Image Scanning with Trivy in Your CI Pipeline</title>
      <link>https://tommeurs.nl/en/posts/trivy-container-scanning/</link>
      <pubDate>Sun, 08 Jun 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/trivy-container-scanning/</guid>
      <description>&lt;p&gt;Pull a base image, copy in your code, push it to production. That&amp;rsquo;s the loop most of us run on autopilot. The part nobody looks at is the base image itself, which quietly drags in a few hundred packages you never chose. Any one of them could carry a known &lt;span class=&#34;def&#34; tabindex=&#34;0&#34; data-def=&#34;Common Vulnerabilities and Exposures: the public identifier for one specific vulnerability, in the form CVE-2026-1234. The identifier says nothing about severity.&#34;&gt;CVE&lt;/span&gt;&#xA;, and you&amp;rsquo;d have no idea.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Automating Semantic Versioning with GitLab CI</title>
      <link>https://tommeurs.nl/en/posts/semantic-versioning-gitlab/</link>
      <pubDate>Tue, 27 May 2025 19:44:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/semantic-versioning-gitlab/</guid>
      <description>&lt;p&gt;Picture the end state first. You merge a branch to main, walk away to get coffee, and by the time you&amp;rsquo;re back the project has a new version tag, a fresh changelog entry, and a GitLab release with notes written from your commits. Nobody decided &amp;ldquo;is this 1.4.0 or 1.3.5?&amp;rdquo; because nobody had to. The version fell out of the work itself.&lt;/p&gt;&#xA;&lt;p&gt;That&amp;rsquo;s where I want to get to in this post. I run a self-hosted GitLab and I do not want versioning to be a thing I think about. A version number that someone picks by hand is a tiny black box: it depends on whether that person remembered the rules, was paying attention, and agreed with everyone else about what counts as a breaking change. I would rather the number be a consequence of the commits, something I can inspect and reproduce.&lt;/p&gt;</description>
    </item>
    <item>
      <title>GitLab CI for Kubernetes: From Commit to Deployment</title>
      <link>https://tommeurs.nl/en/posts/gitlab-ci-kubernetes/</link>
      <pubDate>Thu, 15 May 2025 20:33:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/gitlab-ci-kubernetes/</guid>
      <description>&lt;p&gt;For a long time my CI lived on someone else&amp;rsquo;s servers. Push code, wait for a hosted runner, watch the minutes tick down against a monthly quota, hope the provider doesn&amp;rsquo;t change the rules next quarter. It worked, right up until I started asking where my source code actually sat while it was being built, and who else could see it.&lt;/p&gt;&#xA;&lt;p&gt;So I moved GitLab in-house. I run it self-hosted now, on my own hardware, next to the clusters it deploys to. That&amp;rsquo;s &lt;a href=&#34;https://tommeurs.nl/en/posts/sovereign-infrastructure/&#34;&gt;sovereignty&lt;/a&gt; applied to CI/CD: my code, my builds, my artifacts, no vendor that can change pricing, deprecate a feature I depend on, or read my repositories without me knowing.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
