CI/CD Workflows

Relevant source files

The following files were used as context for generating this wiki page:

• AGENTS.md
• README.md
• cliff.toml
• renovate.json
• Cargo.toml

Hodor utilizes a suite of GitHub Actions workflows to automate code quality enforcement, version management, and containerized deployment. These workflows ensure that every contribution meets the project's standards for security, performance, and functional correctness.

The automation system handles the entire lifecycle of a change, from initial Pull Request validation to the generation of multi-arch Docker images and GitHub releases. The project maintains a strict policy of using standard Rust tools and container linters within these pipelines.
Sources: AGENTS.md:43-47, README.md:275-285

Continuous Integration (CI)

The CI workflow, defined in .github/workflows/ci.yml, executes automatically on every push and Pull Request. It performs a multi-stage validation of the codebase to prevent regression and maintain high code quality standards.

Validation Pipeline

The CI process includes four primary checks:

1. Format Check: Runs cargo fmt -- --check to ensure code adheres to standard Rust formatting.
2. Linting: Executes cargo clippy -- -D warnings to catch common mistakes and enforce project-specific complexity thresholds.
3. Security Scanning: Uses hadolint to validate the project's Dockerfile.
4. Testing and Coverage: Executes the full test suite via cargo test and generates coverage reports using cargo-llvm-cov.

Sources: AGENTS.md:37-41, AGENTS.md:43-44, README.md:275-282

The diagram shows the sequential validation steps required for a successful CI build.
Sources: AGENTS.md:43-44, README.md:280-282

Release and Versioning Workflows

The project automates the release process through two distinct workflows: bump-version.yml and release.yml. This separation allows for controlled version incrementing followed by automated deployment.

Version Bumping

The bump-version.yml workflow is a manual dispatch process. When triggered, it performs the following actions:

• Updates the version in Cargo.toml using cargo set-version.
• Commits the version change.
• Pushes a new git tag in the format vX.Y.Z.

Sources: AGENTS.md:45, Cargo.toml:3-5

Release Automation

The release.yml workflow triggers when a new tag matching the v* pattern is pushed. It handles the generation of release assets and distribution.

Step	Tool / Platform	Result
Changelog	git-cliff	Generates a Markdown changelog based on cliff.toml
Docker Build	Buildx	Builds multi-arch images (scratch-based)
Publishing	GHCR.io	Pushes images to GitHub Container Registry
GitHub Release	GitHub API	Creates a release entry with the generated changelog

Sources: AGENTS.md:46, README.md:286-291, cliff.toml:1-42

This sequence diagram illustrates the handoff between manual version management and automated release delivery.
Sources: AGENTS.md:45-46, cliff.toml:1-10

Dependency and Contribution Management

Hodor maintains project health through automated dependency tracking and strict contribution rules.

Automated Updates

The renovate.json configuration enables automated dependency management. It is configured to:

• Extend the recommended Renovate configuration.
• Enable security vulnerability alerts with a specific label.
• Group all Cargo (Rust) dependencies to minimize PR noise.
• Assign no-stale and bot labels to generated PRs.

Sources: renovate.json:1-19

Contribution Standards

A specialized workflow, pr-title.yml, enforces "Conventional Commits" on all Pull Request titles. This ensures that the automated changelog generation performed by git-cliff in the release workflow is accurate and properly categorized.

Category	Commit Prefix	Description
Features	feat	New functionality
Bug Fixes	fix	Correcting errors
Performance	perf	Speed or resource optimizations
Miscellaneous	chore / ci	Infrastructure or maintenance

Sources: AGENTS.md:47, cliff.toml:30-41

Conclusion

The CI/CD pipeline for Hodor ensures that the "tiny reverse proxy" remains stable and secure. By automating the build of scratch-based Docker images and enforcing strict linting and testing, the project minimizes the risk of introducing vulnerabilities into its mission-critical authentication and proxying logic.
Sources: AGENTS.md:52-58, README.md:1-25