Menu

CI/CD Pipeline and Testing

Relevant source files

This document describes the Continuous Integration and Continuous Deployment (CI/CD) infrastructure for fastfetch, including the GitHub Actions workflow, test strategies, platform build matrix, and release automation. The pipeline ensures code quality and cross-platform compatibility across 20+ operating system and architecture combinations.

For information about the CMake build configuration that underpins these builds, see Cross-Platform Build Configuration. For details on packaging artifacts produced by the CI pipeline, see Packaging and Distribution.


GitHub Actions Workflow Architecture

The CI/CD pipeline is defined in .github/workflows/ci.yml and consists of multiple parallel job stages that execute on push and pull request events. The workflow uses a matrix strategy to test across diverse platforms while maintaining a single source of truth for build configuration.

Workflow Job Structure

Sources: .github/workflows/ci.yml1-813


Test Execution Flow

Each build job executes a standardized test sequence that validates functionality across multiple dimensions. Tests run in a fixed order to catch both build-time and runtime issues.

Standard Test Sequence

The test sequence verifies:

  • Feature Detection: --list-features confirms compiled-in features match expectations
  • Functional Execution: Both text and JSON output modes with comprehensive module set
  • Minimal Build: flashfetch binary (lightweight variant) executes correctly
  • Dependency Hygiene: ldd/otool output validates dynamic linking
  • Unit Tests: ctest executes test suite defined in CMakeLists.txt

Sources: .github/workflows/ci.yml46-62 .github/workflows/ci.yml119-135


Platform Build Matrix

The CI pipeline builds and tests fastfetch on 20+ platform/architecture combinations using a mix of native runners and emulated environments via QEMU.

Linux Builds

ArchitectureRunnerBuild StrategyKey Dependencies
amd64ubuntu-22.04Nativegcc-13, full feature set + CodeQL
aarch64ubuntu-22.04-armNativegcc-13, full feature set
i686ubuntu-22.04Cross-compilegcc-13 multilib, -m32 -march=i686
armv7lubuntu-20.04 (QEMU)Emulatedgcc-13, limited features
armv6lDebian Bookworm (QEMU)Emulatedgcc, limited features
riscv64ubuntu-22.04 (QEMU)Emulatedgcc-13, full feature set
ppc64leubuntu-22.04 (QEMU)Emulatedgcc-13, full feature set
s390xubuntu-22.04 (QEMU)Emulatedgcc-13, full feature set

glibc Polyfill: The amd64 and aarch64 builds apply glibc symbol polyfilling to achieve compatibility with glibc 2.17+, extending compatibility to older Linux distributions.

Sources: .github/workflows/ci.yml64-158 .github/workflows/ci.yml159-220 .github/workflows/ci.yml222-260 .github/workflows/ci.yml262-296 .github/workflows/ci.yml298-339

Musl libc Build

ArchitectureDistributionFeatures
amd64Alpine LinuxStatic linking option, minimal dependencies

The musl build uses Alpine Linux and enables the IS_MUSL flag, which adjusts memory allocation and system call patterns for musl libc compatibility.

Sources: .github/workflows/ci.yml341-377

macOS Builds

ArchitectureRunnerToolchain
amd64 (Intel)macos-15-intelHomebrew clang
aarch64 (Apple Silicon)macos-latestHomebrew clang

macOS builds install dependencies via Homebrew, including vulkan-loader, vulkan-headers, molten-vk, imagemagick, and chafa.

Sources: .github/workflows/ci.yml379-431

Windows Builds

ArchitectureRunnerEnvironmentToolchain
amd64windows-latestMSYS2/CLANG64clang + mingw-w64
aarch64windows-11-armMSYS2/CLANGARM64clang + mingw-w64

Windows builds use MSYS2 with the Clang environment for better standards compliance and cross-platform consistency. Binaries are code-signed using SignPath integration for release builds.

Sources: .github/workflows/ci.yml647-745

BSD and Other Unix Builds

PlatformVersionRunner StrategyPackage Manager
FreeBSD14.3VM (cross-platform-actions)pkg
OpenBSD7.7VM (cross-platform-actions)pkg_add
NetBSD10.1VM (cross-platform-actions)pkgin
DragonFly BSDLatestVM (vmactions)pkg
SunOS (OmniOS)LatestVM (vmactions)pkg
Haikur1beta5VM (cross-platform-actions)pkgman

BSD and other Unix builds execute in virtual machines using GitHub Actions' VM action providers, which configure the environment and install dependencies via platform-native package managers.

Sources: .github/workflows/ci.yml467-502 .github/workflows/ci.yml504-539 .github/workflows/ci.yml541-575 .github/workflows/ci.yml577-610 .github/workflows/ci.yml433-465 .github/workflows/ci.yml612-645


Test Types and Strategies

Spell Check

The spellcheck job runs codespell to detect common spelling errors in source code, comments, and documentation. This catches typos before they reach production.

Sources: .github/workflows/ci.yml11-25

No-Features Test

The no-features-test job builds fastfetch with all optional features disabled to ensure the codebase compiles and functions with minimal dependencies. This validates that feature flags are correctly implemented and that no feature has become accidentally required.

Sources: .github/workflows/ci.yml27-62

CodeQL Security Analysis

The linux-hosts job on amd64 includes GitHub CodeQL analysis for C code. CodeQL performs static analysis to identify potential security vulnerabilities, code quality issues, and common programming errors.

Sources: .github/workflows/ci.yml103-107 .github/workflows/ci.yml115-117

Functional Testing with CI Preset

All build jobs execute fastfetch with presets/ci.jsonc, which enables a comprehensive set of modules to exercise detection logic across all subsystems. The preset is designed for CI environments with:

  • No logo rendering ("logo": null) to avoid terminal compatibility issues
  • All modules enabled (70+ modules) including optional temperature and driver-specific queries
  • Statistics enabled ("stat": true) to verify performance metrics collection
  • Pipe mode ("pipe": true) for clean output
  • Error display ("showErrors": true) to surface issues

The CI preset configuration:

Sources: presets/ci.jsonc1-115

Key characteristics:

  • Tests all major detection subsystems (CPU, GPU, Memory, Disk, Display, etc.)
  • Includes network modules with 1-second timeouts to prevent CI hangs
  • Enables driver-specific GPU detection ("driverSpecific": true)
  • Tests temperature sensors where available
  • Validates both text and JSON output modes

Unit Testing with CTest

The test suite executes via ctest --output-on-failure, which runs unit tests for core data structures and utilities. Tests are defined in CMakeLists.txt with -DBUILD_TESTS=On.

Common test targets:

  • FFstrbuf tests: Dynamic string manipulation, memory management
  • FFlist tests: Dynamic array operations, resizing
  • Platform utility tests: File I/O, process management

Sources: .github/workflows/ci.yml61-62 .github/workflows/ci.yml134-135


Dependency Management Strategy

Dependencies are installed differently per platform to balance availability, version requirements, and build reproducibility:

Linux: apt + Linuxbrew Hybrid

Linuxbrew provides newer ImageMagick versions than Ubuntu repositories, with --ignore-dependencies to avoid pulling unnecessary dependencies.

Sources: .github/workflows/ci.yml92-101

macOS: Homebrew

The HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK=1 environment variable prevents Homebrew from attempting to rebuild dependent packages, speeding up CI runs.

Sources: .github/workflows/ci.yml399-401

Windows: MSYS2

MSYS2 packages are prefixed with mingw-w64-clang-$ARCH- for the Clang toolchain:

Sources: .github/workflows/ci.yml673-678


Release Automation

The release job creates GitHub releases automatically when new versions are detected on the master branch.

Release Process Details

The release job only executes when:

  1. Triggered by a push to master branch
  2. Repository is fastfetch-cli/fastfetch (prevents forks from releasing)
  3. All platform build jobs complete successfully
  4. Detected version differs from latest GitHub release

Version detection:

This output is captured in linux-hosts job and passed to the release job via job outputs.

Sources: .github/workflows/ci.yml137-139 .github/workflows/ci.yml746-812

Checksum Generation

Release notes include SHA256 and SHA512 checksums for all artifacts in collapsible Markdown sections:

[checksums listed here]

 </details> <details><summary>SHA512SUMs</summary><br> 

[checksums listed here]

 </details> 

Sources: .github/workflows/ci.yml794-803


Code Signing (Windows)

Windows builds integrate with SignPath for code signing, which is required for SmartScreen reputation and user trust. The signing process occurs as a separate step after building:

Signing Configuration

  • Production Signing: Triggered on master branch (signing-policy-slug: 'release-signing')
  • Test Signing: Triggered on other branches (signing-policy-slug: 'test-signing')
  • Authenticode: Windows Authenticode signatures applied to .exe files
  • Artifact Overwrite: Signed artifacts replace unsigned artifacts using overwrite: true

Sources: .github/workflows/ci.yml710-744


Artifact Generation and Naming

Build artifacts follow a consistent naming convention:

PlatformFormatExample
LinuxDEBfastfetch-linux-amd64.deb
LinuxRPMfastfetch-linux-amd64.rpm
Linux (polyfilled)DEBfastfetch-linux-amd64-polyfilled.deb
macOSDMGfastfetch-macos-aarch64.dmg
WindowsZIPfastfetch-windows-amd64.zip
Windows7zfastfetch-windows-amd64.7z
BSDTGZfastfetch-freebsd-amd64.tar.gz

The --target package flag to cmake --build invokes CPack to generate platform-appropriate packages. Polyfilled Linux builds append -polyfilled to the package name to indicate glibc compatibility patching.

Sources: .github/workflows/ci.yml113 .github/workflows/ci.yml147-151 .github/workflows/ci.yml733-737


Embedded Data Generation

Several build jobs enable embedded data to reduce runtime dependencies:

The PCI IDs database is generated from pci.ids via scripts/gen-pciids.py, which filters vendors relevant to GPU detection:

The script generates fastfetch_pciids.c.inc containing FFPciVendor and FFPciDevice structures for offline GPU name resolution.

Sources: .github/workflows/ci.yml110 scripts/gen-pciids.py1-96


Performance Monitoring

Test executions include timing via the time command to track performance regressions:

The --stat false flag suppresses statistics display while still collecting them internally. This provides baseline timing data without visual overhead.

Sources: .github/workflows/ci.yml50 .github/workflows/ci.yml52 .github/workflows/ci.yml55


Module Registry Testing

The CI preset exercises the entire module registry defined in src/common/modules.c. The registry organizes 70+ modules in alphabetical arrays (A[] through Z[]), indexed by module name's first letter.

Module Coverage in CI

The CI preset tests modules from all registry categories:

LetterModules Tested
BBattery, BIOS, Board, Bootmgr, Break, Brightness, Btrfs
CCamera, Chassis, Colors, CPU, CPUCache, CPUUsage, Cursor
DDateTime, DE, Display, Disk, DiskIO, DNS
EEditor
FFont
GGamepad, GPU
HHost
IIcons, InitSystem
KKernel, Keyboard
LLM, Loadavg, Locale, LocalIP
MMedia, Memory, Monitor, Mouse
NNetIO
OOpenCL, OpenGL, OS
PPackages, PhysicalDisk, PhysicalMemory, Player, PowerAdapter, Processes, PublicIP
SSeparator, Shell, Sound, Swap
TTerminal, TerminalFont, TerminalSize, TerminalTheme, Theme, Title, TPM
UUptime, Users
VVersion, Vulkan
WWallpaper, Weather, WM, WMTheme, Wifi
ZZpool

This comprehensive testing ensures all detection paths are validated on every platform build.

Sources: presets/ci.jsonc10-114 src/common/modules.c1-183


CI Environment Variables

The workflow defines global environment variables for consistency:

This allows repository owners to override the default build type via GitHub Actions variables while defaulting to RelWithDebInfo (optimized with debug symbols) for release builds.

Sources: .github/workflows/ci.yml7-8