​

GitHub Actions Workflows

Terra Packages uses GitHub Actions to automate package building, testing, and deployment. The CI/CD system is built around five core workflows that handle different aspects of the build process.

​

Workflow Overview

Terra Packages implements a sophisticated multi-stage CI/CD pipeline:

1. Autobuild - Automatically builds packages when changes are detected
2. Manual Build - Allows manual package building with custom parameters
3. JSON Build - Core build engine called by other workflows
4. Bootstrap - Bootstraps the build system and core tooling
5. Update - Automatically updates package versions

​

Autobuild Workflow

The autobuild workflow (autobuild.yml) is the primary CI/CD pipeline that automatically builds packages when changes are pushed to the repository.

​

Triggers

The workflow triggers on:

• Pushes to the frawhide branch that modify files under anda/
• Pull requests targeting frawhide
• Merge queue events
• Manual workflow dispatch
• Calls from other workflows

​

Build Matrix Generation

The first job generates a build matrix by scanning for changed packages:

​

Build Job

The build job delegates to the JSON Build workflow:

​

AppStream Generation

After building, the workflow generates AppStream metadata for package discovery: The AppStream generation step creates metadata catalogs and reports any vetoed packages in the GitHub Actions summary.

​

Manual Build Workflow

The manual build workflow (build.yml) allows maintainers to build specific packages on-demand with custom configurations.

​

Workflow Inputs

​

Dynamic Run Names

The workflow run is named after the packages being built for easy identification.

​

Package Parsing

The manifest job processes the input packages and generates a build matrix:

​

JSON Build Workflow

The JSON Build workflow (json-build.yml) is the core build engine that performs the actual package compilation. It’s designed to be called by other workflows.

​

Workflow Call Interface

​

Dynamic Runner Selection

The workflow intelligently selects runners based on architecture and package size:

​

Compiler Cache (sccache)

The workflow uses sccache for distributed compilation caching: Caching is keyed by version, architecture, and package name to ensure cache hits for repeated builds.

​

Build Process

The build process consists of several stages:

​

Artifact Upload

Built packages are uploaded as workflow artifacts:

​

Repository Upload

When publishing is enabled, packages are uploaded to the Subatomic repository: Packages can be uploaded to sub-repositories using the subrepo label, and source package uploads can be disabled with the no_upload_srpms=1 label.

​

Build Notifications

The workflow notifies Madoguchi (the build tracking service) of build results:

​

Bootstrap Workflow

The bootstrap workflow (bootstrap.yml) builds the core build system tools from scratch using only Fedora base packages.

​

Build Matrix

​

Bootstrap Process

The bootstrap follows a specific order to build the toolchain: The bootstrap sequence:

1. Install base system tools
2. Build anda-srpm-macros using rpmbuild
3. Install anda-srpm-macros
4. Install build dependencies
5. Build and install Anda
6. Use Anda to build remaining packages

​

Update Workflow

The update workflow (update.yml) automatically checks for and applies package version updates.

​

Schedule

The workflow runs every 10 minutes to check for updates.

​

Update Process

​

Multi-Branch Commits

When updates are found, they’re committed to multiple release branches: The workflow uses git format-patch to apply the same updates to multiple release branches (f44, f43, f42, el10).

​

Workflow Permissions

All workflows follow the principle of least privilege: