Architectural Decision Record

ADR 1: Pipeline Engine Selection

Field	Details

Field	Details
Title	CI Pipeline Engine for Eureka
Date	2025-07-17
Status	✅ Approved
Context	The Eureka CI process needs a scalable, integrated pipeline engine. Options considered include Jenkins and GitHub Actions.
Decision	Use GitHub Actions as the primary CI/CD engine for Eureka CI, due to ease of use, GitHub-native integration, lower maintenance overhead, and good fit for the public OSS ecosystem.
Alternatives Considered	Jenkins: powerful, customizable, but heavy infra and maintenance GitHub Actions: lightweight, scalable with self-hosted runners, integrated with GitHub UI
Consequences	✅ Simpler onboarding for developers ✅ Cost-effective for public repos ⚠️ Potential queuing at peak load (addressed in ADR 2) ⚠️ Some limitations for complex multi-repo orchestration
Related Documents	Pipeline engine alternatives \|\| RANCHER-2326
Authors / Reviewers	Kitfox Team

Field	Details

Field	Details
Title	GitHub Actions Runners Strategy
Date	2025-07-17
Status	✅ Approved
Context	Runner infrastructure must support dozens of concurrent pipelines across Eureka applications. GitHub-hosted runners are limited but easy to adopt. Self-hosted runners offer scalability but need ops investment.
Decision	Use GitHub-hosted runners as the default. Evaluate self-hosted runners on AWS EKS later for high-frequency workflows.
Alternatives Considered	GitHub-hosted: Free for OSS, simple, but limited in concurrency EKS-based runners: Scalable, customizable, but requires operational support
Consequences	✅ Fast adoption with GitHub-hosted runners ✅ PoC in place for self-hosted scale-up path ⚠️ Operational complexity deferred to phase 2
Related Documents	Self-hosted GitHub runners on AWS EKS
Authors / Reviewers	Kitfox Team

Field	Details

Field	Details
Title	Scripting Language for GitHub Actions
Date	2025-07-17
Status	✅ Approved
Context	CI workflows include descriptor validation, API interaction, metadata publishing, etc. Teams must choose between Shell, Python, or both.
Decision	Adopt a hybrid scripting approach: Use Shell for small utilities and Git tasks Use Python for structured validation, API calls, and reusable logic Use marketplace actions only from verified publishers
Alternatives Considered	Shell: Lightweight but hard to scale Python: Structured, testable, but requires dependencies Hybrid: Combines strengths of both
Consequences	✅ Clear code boundaries ✅ Maintainable workflows with unit-testable Python ⚠️ Slight overhead managing dual scripting environments
Related Documents	Scripting approach (Shell vs Python) for GitHub Actions
Authors / Reviewers	Kitfox Team

Field	Details

Field	Details
Title	Application Descriptor Registry for Eureka
Date	2025-07-17
Status	✅ Approved
Context	Eureka CI pipeline requires a registry for application descriptors (release, snapshot, custom). Options include S3, GitHub repo, Nexus, or mgr-applications (FAR).
Decision	Use mgr-applications in FAR mode, deployed via AWS Elastic Beanstalk with RDS for HA or EKS with self-hosted PostgreSQL and EBS backup strategy.
Alternatives Considered	S3: Durable, cheap, but lacks metadata search GitHub repo: Traceable, but no structured API Nexus: Full-featured, but heavy infra mgr-applications FAR: Purpose-built, flexible API
Consequences	✅ Full CRUD API + filtering by name, releaseType ✅ HA possible with RDS Multi-AZ ⚠️ Requires PostgreSQL + reverse proxy for auth
Related Documents	Application registry hosting approach
Authors / Reviewers	Kitfox Team