website-and-documentation/content/en/docs/components/forgejo/forgejo.md

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

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

• Jira Ticket: TICKET-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 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., 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). 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.

• 🚀 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.