Testing and Continuous Delivery
Your Cluster is Lying to ArgoCD (And How to Catch It)
<p>We love ArgoCD, but it creates a classic "map vs. territory" problem. We treat Git as our "map", our single source of truth. But the cluster is the "territory", and it's often more complex than the map shows.
This becomes a crisis with the 3 AM hotfix: an SRE fixes production, changing the territory. ArgoCD, loyal to the map, sees this as drift and helpfully overwrites the fix, re-breaking the cluster.
The problem is that Git isn't our Truth, it's our Intention. This talk introduces a pragmatic solution: Cluster-Scoped Snapshotting. We’ll show a simple pattern that dumps the entire live cluster state (the "territory") into its own "reality" Git repo. To automate this, we wrote a small open-source tool called Kalco, but the pattern is the real takeaway.
This "reality" repo gives us a powerful "pre-flight diff" in our CI pipeline, comparing our "intention" (the app repo) against the "truth" (the snapshot repo). This simple check lets us bootstrap existing clusters, create a complete audit log, and stop our pipeline before it merges a change that conflicts with a critical live fix.</p>
Additional information
| Live Stream | https://live.fosdem.org/watch/h2213 |
|---|---|
| Type | devroom |
| Language | English |
More sessions
| 2/1/26 |
<p>A number of industrial applications now demand hard real-time scheduling capabilities from the kernel of a Linux-based operating system, but scheduling measurements from the system itself cannot be completely trusted as they are referenced to the same clock as the kernel-under-test. Yet, if the system can output signals to hardware as it runs, their timing can be analysed by an external microcontroller, and a second "external" measurement obtained to compare with the system's own report.</p> ...
|
| 2/1/26 |
<p>OS kernel development is often connected with time consuming testing process and non-trivial debug technics. Although emulators like QEMU and Bochs ease this work significantly, nothing can compare with convenience of userspace developer environment. Moving parts of the kernel to the userspace binary is not straightforward, especially if the kernel has almost no compatibility with POSIX and is written entirely in assembly. Still, sometimes it is doable. The talk shares experience, ...
|
| 2/1/26 |
<p>Talk about a project that implements a hardware-in-the-loop testing framework for validating Linux distributions on specific development boards. The system uses a universal testing harness that automatically detects target hardware platforms and adapts generic testing scripts to board-specific configurations with Claude AI help. Platform adaptation is achieved through specific configuration files that define board-specific parameters, enabling the same testing codebase to validate different ...
|
| 2/1/26 |
<p>The <strong>ci-multiplatform</strong> project is a generic, OCI-based multi-architecture CI system designed to make cross-platform testing practical for open-source projects using GitLab CI. Originally created while enabling RISC-V support for Pixman (https://gitlab.freedesktop.org/pixman/pixman), it has since grown into an independent project under the RISE (RISC-V Software Ecosystem) umbrella: https://gitlab.com/riseproject/CI/ci-multiplatform, with a mirror on freedesktop.org: ...
|
| 2/1/26 |
<p>Testing is central to modern software quality, yet many widely used Fortran codebases still lack automated tests. Existing tests are often limited to coarse end-to-end regression checks that provide only partial confidence. With the growth of open-source Fortran tools, we can now bring unit testing and continuous validation to legacy and modern Fortran projects alike. </p> <p>This talk surveys the current landscape of Fortran testing frameworks before focusing on three I have evaluated in ...
|
| 2/1/26 |
<p>ESPHome is a versatile framework to create custom firmware for various microcontrollers. In this talks we will look at how to automatically test the latest ESPHome firmware on an ESP32.</p> <p>As ESPHome devices are used to interact with the real world, we will also look at how to test that the LUX sensors is able to detect light variations.</p> <p>In order to test the ESP32 device, we are going to use lava on the command line, directly inside a gitlab runner.</p>
|
| 2/1/26 |
<p>The CI/CD server Jenkins provides powerful build-quality visualizations through plugins such as <a href="https://plugins.jenkins.io/warnings-ng/">Warnings</a>, <a href="https://plugins.jenkins.io/coverage/">Coverage</a>, and <a href="https://plugins.jenkins.io/git-forensics/">Git Forensics</a>. These plugins aggregate and visualize data from static analysis tools, coverage reports, software metrics, and Git history, enabling teams to track quality trends across builds. We have now brought ...
|
