Julian FoadForgeFed packaging: overview
- Trax/Projects/ForgeFed/forgefed-packaging/overview
- Trax/Projects/ForgeFed/forgefed-packaging/NGI-proposal
This proposal is to package software components related to the development of forge federation.
To encourage and facilitate work on forge federation, by making it easier for both developers and early adopters to host the components, by providing integrations into existing hosting frameworks.
We are talking about web service deployment packaging (like Docker, Yunohost) rather than OS-level packaging (like Deb, RPM).
Why spend effort on this kind of packaging?
Developers of a piece of software know how to run it locally for development and testing.
Developers integrating multiple components need a way to deploy them all, easily, repeatably, and with the ability to switch between variants of each (such as development and production versions).
Hosting frameworks make this job a whole lot easier.
Why target multiple packaging formats together?
Spread. There is a need to develop hosting systems further, across the FOSS scale, from those supporting the grass-roots FOSS developers, up to those deployed by service providers.
Efficiency. Being familiar with a particular hosting framework makes it easier to package more apps for it. Being familiar with a particular app makes it easier to package it for more hosting frameworks. Tackling the basic hosting needs in a consistent and efficient way then allows to devote effort beyond the basics, to capabilities like backup/restore, DNS/well-known configuration, single-sign-on, integration with a landing page.
Target Components, Hosting, Capabilities
Hosting frameworks targeted:
- Yunohost, popular grass-roots self-hosting system-in-a-box (Debian-based)
- MASH, sibling of professional quality Matrix-docker-ansible-deploy (Docker-based)
- SHB? (Nix-based)
- K8S? (K8s-based)
- Fediversity? (Nix/K8s-based?)
ForgeFed components targeted, main:
- Forgejo (already in YNH, MASH)
- Vervis
- Anvil
Additional components useful in a real forge deployment:
- Forgejo Runner (already in MASH)
- Woodpecker CI (server + agent) (already in MASH)
- Weblate (already in YNH)
Implementation Status
| . | YNH | MASH | SHB | K8S |
|---|---|---|---|---|
| Vervis | no | no | no | ? |
| Anvil | no | no | no | ? |
| Forgejo | yes S,A,B,D,L,M | yes C... | yes S,A,B... | ? |
| Forgejo-Runner | no | yes C... | yes S,A,B... | yes |
| Woodpecker-CI | yes B,D,L,M | yes C... | no | ? |
| Weblate | yes B,D,L,M | no | no | ? |
Integration features:
- S. Single sign-on (SSO)
- A. Accounts managed externally (LDAP)
- B. Backup/restore
- C. Containerised
- D. DNS/well-known configuration
- L. Launcher/landing page integration
- M. Multiple installs (on different domains/paths)
About The Components
Forgejo Runner
Forgejo Actions provides CI services, running CI jobs on (remote) agents such as Forgejo Runner or alternatives.
Rationale for inclusion: commonly used with Forgejo.
Woodpecker CI
Woodpecker CI consists of server and runner (agent), and performs CI services for a forge. It is an alternative to using Forgejo Actions.
Rationale for inclusion: Codeberg offers an integrated Woodpecker CI service.
Woodpecker's Forgejo integration documentation
How Libre? Apache-2/CC-BY-SA, Github, Mastodon, Matrix, Xtwitter
Weblate
Weblate provides translation and localisation services. As copy-left libre software it complements a libre forge.
Rationale for inclusion: Codeberg offers an integrated Weblate service.
How Libre? GPL, Github, Mastodon, Xtw/FB/LI...
#Forgejo #forgeFed #forgeFederation #selfHosted #NGI