8 KiB
| title | date | description | tags | categories | mermaid | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Edge Developer Platform: Forgejo Integration & GARM Extension | 2025-11-19 | Technical report on the implementation of the Edge Developer Platform (EDP) using Forgejo, featuring GARM integration for ephemeral CI/CD runners and upstream open-source contributions. |
|
|
true |
1. Project Identity & Governance
1.1 Project Scope
The internal service is officially designated as the Edge Developer Platform (EDP). It is hosted at edp.buildth.ing. The domain selection followed a democratic team process to establish a unique identity distinct from standard corporate naming conventions.
Access Model: The platform operates on a hybrid visibility model:
- Public Access: The
DEVFW-CICDorganization is publicly accessible, fostering transparency. - Private Access: Sensitive development occurs in restricted organizations (e.g.,
DEVFW). - User Base: Primary users include the internal development team, with friendly user access granted to the IPCEI team and MMS BT.
1.2 Strategic Selection & Governance
The decision to utilize Forgejo as the core self-hosted Git service was driven by specific strategic requirements:
- EU-Based Stewardship: Forgejo is stewarded by Codeberg e.V., a non-profit organization based in Berlin, Germany. This alignment ensures compliance with GDPR and data sovereignty requirements, placing governance under EU jurisdiction rather than US tech entities.
- License Protection (GPL v3+): Unlike "Open Core" models, Forgejo uses a copyleft license. This legally protects our custom extensions (such as GARM support) from being appropriated into proprietary software, ensuring the ecosystem remains open.
- Open Source Strategy: The platform aligns with the "Public Money, Public Code" philosophy, mandating that funded developments are returned to the community.
2. Technical Architecture & Deployment
2.1 Infrastructure Stack
The platform is hosted on the Open Telekom Cloud (OTC). The infrastructure adheres to Infrastructure-as-Code (IaC) principles.
- Deployment Method: The official Forgejo Helm Chart is deployed via ArgoCD.
- Infrastructure Provisioning: Terraform is used to provision all underlying OTC services, including:
- Container Orchestration: CCE (Cloud Container Engine): Kubernetes
- Database: RDS (Distributed Cache Service): PostgreSQL
- Caching: DCS (Distributed Cache Service): Redis
- Object Storage: OBS (Object Storage Service, S3-compatible): for user data (avatars, attachments).
- Search: CSS (Cloud Search Service): Elasticsearch
2.2 The "Self-Replicating" Pipeline
A key architectural feature is the ability of the platform to maintain itself. A Forgejo Action can trigger the deployment script, which runs Terraform and syncs ArgoCD, effectively allowing "Forgejo to create/update Forgejo."
graph TD
subgraph "Open Telekom Cloud (OTC)"
subgraph "Control Plane"
Dev[DevOps Engineer] -->|Triggers| Pipeline[Deployment Pipeline]
Pipeline -->|Executes| TF[Terraform]
end
subgraph "Provisioned Infrastructure"
TF -->|Provisions| CCE[(CCE K8s Cluster)]
TF -->|Provisions| RDS[(RDS PostgreSQL)]
TF -->|Provisions| Redis[(DCS Redis)]
TF -->|Provisions| S3[(OBS S3 Bucket)]
TF -->|Provisions| CSS[(CSS Elasticsearch)]
end
subgraph "Application Layer (on CCE K8s)"
Pipeline -->|Helm Chart| Argo[ArgoCD]
Argo -->|Deploys| ForgejoApp[Forgejo]
end
CCE -- Runs --> Argo
CCE -- Runs --> ForgejoApp
ForgejoApp -->|Connects| RDS
ForgejoApp -->|Connects| Redis
ForgejoApp -->|Connects| S3
ForgejoApp -->|Connects| CSS
end
2.3 Migration History
The initial environment was a manual setup on the Open Sovereign Cloud (OSC). Once the automation stack (Terraform/ArgoCD) was matured, the platform was migrated to the current OTC environment.
3. Application Extensions & GARM Integration
3.1 Core Functionality
Beyond standard Git versioning, the platform utilizes:
- Releases: Hosting binaries for software distribution (e.g., Edge Connect CLI).
- CI/CD: Extensive pipeline usage for build, test, and deployment automation.
- Note on Issues: While initially used, issue tracking was migrated to JIRA to align with the broader IPCEI program standards.
3.2 GARM (Git-based Actions Runner Manager)
The primary technical innovation was the integration of GARM to enable ephemeral, scalable runners. This required extending Forgejo's capabilities to support GitHub-compatible runner registration and webhook events.
Workflow Architecture:
- Event: A workflow event occurs in Forgejo.
- Trigger: A webhook notifies GARM.
- Provisioning: GARM spins up a fresh, ephemeral runner.
- Execution: The runner registers via the API, executes the job, and is terminated immediately after, ensuring a clean build environment.
sequenceDiagram
participant User
participant Forgejo
participant GARM
participant Runner as Ephemeral Runner
User->>Forgejo: Push Code / Trigger Event
Forgejo->>GARM: Webhook Event (Workflow Dispatch)
GARM->>Forgejo: Register Runner (via API)
GARM->>Runner: Spin up Instance
Runner->>Forgejo: Request Job
Forgejo->>Runner: Send Job Payload
Runner->>Runner: Execute Steps
Runner->>Forgejo: Report Status
GARM->>Runner: Terminate (Ephemeral)
4. Development Methodology & Contributions
4.1 Workflow
- Branching Strategy: Trunk-based development was utilized to ensure rapid integration.
- Collaboration: The team adopted Mob Programming. This practice proved essential for knowledge sharing and onboarding junior developers, creating a resilient and high-intensity learning environment.
- Versions: The platform evolved from Forgejo v7/8 to the current v11.0.3-edp1. An upgrade is pending to leverage the latest upstream GARM features.
4.2 Open Source Contributions
We actively contributed our extensions back to the upstream Forgejo project on Codeberg.org.
Key Pull Requests:
- API Compatibility: Added GitHub-compatible endpoints for runner registration.
- Webhook Support: Implemented webhook triggers for workflow events.
- Ephemeral Runners: Added support for runners that terminate after a single job.
Artifact Caching (Pull-Through Proxy): We implemented a feature allowing Forgejo to act as a pull-through proxy for remote container registries, optimizing bandwidth and build speeds.
5. Key Performance Indicators (KPIs)
| KPI | Description | Target / Benchmark |
|---|---|---|
| Deployment Frequency | Frequency of successful pipeline executions. | High (Daily/On-demand) |
| Artifact Cache Hit Rate | Percentage of build requests served by the local Forgejo proxy. | > 90% (Reduced external traffic) |
| Upstream Contribution | Percentage of GARM-related features contributed back to Codeberg. | 100% (No vendor lock-in) |
| PR Resolution Time | Average time for upstream community review and merge. | < 14 days (Healthy collaboration) |