---
title: "Forgejo Integration, Extension, and Community Collaboration"
linkTitle: Forgejo Software Forge
date: "2025-11-17"
description: "Summary of the project's work integrating GARM with Forgejo and contributing key features back to the community."
tags: ["Forgejo", "GARM", "CI/CD", "OSS", "Community", "Project Report"]
categories: ["Workpackage Results"]
weight: 10
---

{{% alert title="Draft" color="warning" %}}
**Editorial Status**: This page is currently being developed.

* **Jira Ticket**: [TICKET-6731](https://jira.telekom-mms.com/browse/IPCEICIS-6731)
* **Assignee**: Daniel
* **Status**: Draft
* **Last Updated**: 2025-11-17
* **TODO**:
  * [ ] Add concrete quick start steps
  * [ ] Include prerequisites and access information
  * [ ] Create first application tutorial
* **Review/Feedback**:
  * [ ] Stephan: 
    * in general:
      * [ ] some parts are worth to go th 'Governance'
      * [ ] perhaps we should remove the emojis?
      * [ ] perhaps we should avoid the impression that the text was copy/pated from AI
    * some details/further ideas:
      * [ ] where is it, this Forgejo? Why is it called 'edp.buildth.ing'?
        * [ ] what are the components we use - package managament, actions, ...
      * [ ] Friendly users? organisations? Public/private stuff?
      * [ ] App Management discussions (we don't!)?
      * [ ] what about code snippets how forgejo is deployed? SSO? user base? Federation options?
        * [ ] storages, Redis, Postgres ... deployment options ... helm charts ...
      * [ ] Migrations we did, where is the migration code?
        * [ ] git POSIX filesystem concurrency discussion, S/3 bucket
      * [ ] what is our general experience?
        * [ ] repository centric domain data model
      * [ ] how did we develop? which version did we take first? how did we upgrade? 
        * [ ] which development flows did we use? which pipleines?
      * [ ] provide codeberg links for the PRs
      * [ ] provide architecture drawings and repo links for the cache registry thing
      * [ ] provide a hight level actions arch diagram from the perspective of forgejo - link to the GARM component here
{{% /alert %}}

## 🧾 Result short description / cognitions

Here is the management summary of the work package results:

* **📈 Strategic Selection:** We chose **[Forgejo](https://forgejo.org/)** as the project's self-hosted Git service. This decision was based on several key strategic factors:
  * **EU-Based & Data Sovereignty:** The project is stewarded by **[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)**, a non-profit based in Berlin, Germany. This is a massive win for our "funding agency" stakeholders, as it aligns with **GDPR, compliance, and data sovereignty goals**. It's governed by EU laws, not a US tech entity.
  * **True Open Source (GPL v3+):** Forgejo is a community-driven fork of Gitea, created to *guarantee* it stays 100% free and open-source (FOSS).
  * **License Protects Our Contributions:** It uses the **GPL v3+ "copyleft" license**. This is *perfect* for our collaboration goal. It legally ensures that the features we contribute back (like GARM support) can **never be taken and locked into a proprietary, closed-source product by anyone**. It protects our work and keeps the community open.

* **⚙️ Core Use Case:** Forgejo is used for all project source code **versioning** and as the backbone for our **CI/CD (Continuous Integration/Continuous Deployment)** pipelines.

* **🛠️ Key Extension (GARM Support):** The main technical achievement was integrating **[GARM (GitHub Actions Runner Manager)](https://github.com/cloudbase/garm)**. This was *not* supported by Forgejo out-of-the-box.

* **✨ Required Enhancements:** To make GARM work, our team developed and implemented several critical features:
  * Webhook support for workflow events (to tell runners when to start).
  * Support for ephemeral runners (for secure, clean-slate builds every time).
  * GitHub API-compatible endpoints (to allow the runners to register themselves correctly).

* **💖 Community Contribution:** We didn't just keep this for ourselves! We contributed all these features **directly back to the upstream Forgejo community**. This wasn't just a code-dump; we actively collaborated via **issues**, **feature requests**, and **pull requests (PRs) on [codeberg.org](https://codeberg.org/)**.

* **🚀 Bonus Functionality:** We also implemented **artifact caching**. This configures Forgejo to act as a **pull-through proxy** for remote container registries (like Docker Hub), which seriously speeds up our build times and saves bandwidth.

---

## 📊 Key Performance Indicators (KPIs)

These metrics assess the success of the work package across technical quality, development efficiency, and open-source engagement.

### 🚀 CI/CD & Delivery Efficiency

These KPIs measure the effectiveness of the Forgejo + GARM setup.

| KPI | Description | Target / Benchmark |
| :--- | :--- | :--- |
| **Deployment Frequency** | How often changes are successfully pushed to production/staging (e.g., deploys per day/week). | High frequency (daily or better) indicates high agility. |
| **Change Failure Rate (CFR)** | Percentage of deployments that require immediate remediation (e.g., a rollback or hotfix). | Below 5% (Industry standard for high performance). |
| **Cycle Time** | Time from the first commit to deployment/release. | Measured in days, trending downward, indicating pipeline efficiency. |
| **Artifact Cache Hit Rate** | Percentage of build requests successfully served by the local Forgejo proxy cache. | **90%+** demonstrates effective use of the proxy and reduced external dependencies. |

### 💖 Open Source & Community Engagement

These KPIs quantify our strategic commitment to the Forgejo community.

| KPI | Description | Target / Benchmark |
| :--- | :--- | :--- |
| **Upstream Contribution Ratio** | Percentage of project code (GARM-related features) committed to Forgejo's upstream repositories versus being maintained in a private fork. | **100%** demonstrates full commitment to collaboration. |
| **Pull Request (PR) Resolution Time** | Average time taken for a PR submitted to Codeberg to be merged or closed by the Forgejo community. | Trending downward (e.g., < 7 days) indicates healthy, responsive collaboration. |
| **Number of Accepted External PRs** | Count of community-submitted features/fixes related to our GARM extension that we review/merge into our implementation. | Increase over time indicates growing external adoption/interest in our work. |