Compare commits
14 commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 4ddd38bed7 | |||
| 1dc8c5cef4 | |||
| 9732eff09a | |||
| 0e45640871 | |||
| 0072d648c4 | |||
| 32ae08d4e9 | |||
| aa5ef6d574 | |||
| 954ac2e63c | |||
| 252ce2550f | |||
| 64cf9f0b1f | |||
| e691c20612 | |||
| fdfde540c8 | |||
| 79132b8bf5 | |||
| 34e5ffc7bc |
55 changed files with 3141 additions and 94 deletions
5
.pre-commit-config.yaml
Normal file
5
.pre-commit-config.yaml
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
repos:
|
||||
- repo: https://github.com/pre-commit/mirrors-prettier
|
||||
rev: "v2.7.1"
|
||||
hooks:
|
||||
- id: prettier
|
||||
1
.prettierignore
Normal file
1
.prettierignore
Normal file
|
|
@ -0,0 +1 @@
|
|||
/book
|
||||
4
.prettierrc
Normal file
4
.prettierrc
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
{
|
||||
"printWidth": 88,
|
||||
"proseWrap": "always"
|
||||
}
|
||||
|
|
@ -1,6 +1,5 @@
|
|||
when:
|
||||
branch: main
|
||||
path: src/*
|
||||
|
||||
pipeline:
|
||||
build:
|
||||
|
|
@ -16,5 +15,6 @@ pipeline:
|
|||
- talon_key
|
||||
commands:
|
||||
- apk add curl jq
|
||||
- curl -SsL -o upload.sh "https://code.thetadev.de/ThetaDev/Talon/raw/branch/main/scripts/upload.sh"
|
||||
- curl -SsL -o upload.sh
|
||||
"https://code.thetadev.de/ThetaDev/Talon/raw/branch/main/scripts/upload.sh"
|
||||
- sh upload.sh book
|
||||
|
|
|
|||
16
README.md
16
README.md
|
|
@ -1,5 +1,7 @@
|
|||
# WPF: Open Source Software
|
||||
|
||||
Dies ist die
|
||||
|
||||
**Kursseite:** http://hhoegl.informatik.hs-augsburg.de/hhwiki/OSS23
|
||||
|
||||
## Build
|
||||
|
|
@ -10,3 +12,17 @@ Die Dokumentation wird mit mdBook (https://rust-lang.github.io/mdBook/) gebaut.
|
|||
mdbook serve # Starte Server mit Live-Update
|
||||
mdbook build # Webseite bauen
|
||||
```
|
||||
|
||||
## Markdown formatieren
|
||||
|
||||
Das Projekt enthält eine Prettier-Konfiguration, um den Markdown-Text zu formatieren
|
||||
(automatische Zeilenumbrüche).
|
||||
|
||||
```bash
|
||||
npx prettier -w .
|
||||
```
|
||||
|
||||
## Lizenz
|
||||
|
||||
Die Dokumentation ist unter der Creative Commons Attribution-ShareAlike 4.0-Lizenz
|
||||
veröffentlicht.
|
||||
|
|
|
|||
|
|
@ -5,3 +5,14 @@
|
|||
- [Aufgabe 1](./aufgaben/aufgabe_1.md)
|
||||
- [Aufgabe 2](./aufgaben/aufgabe_2.md)
|
||||
- [Aufgabe 3](./aufgaben/aufgabe_3.md)
|
||||
- [Aufgabe 4](./aufgaben/aufgabe_4.md)
|
||||
- [Aufgabe 5](./aufgaben/aufgabe_5.md)
|
||||
|
||||
# Selfhosting von Open-Source-Entwicklertools
|
||||
|
||||
- [Einleitung](./studienarbeit/1_einleitung.md)
|
||||
- [GitLab](./studienarbeit/2_gitlab.md)
|
||||
- [Gitea](./studienarbeit/3_gitea.md)
|
||||
- [Sourcehut](./studienarbeit/4_sourcehut.md)
|
||||
- [OneDev](./studienarbeit/5_onedev.md)
|
||||
- [Anhang: Sourcehut-Setup](./studienarbeit/sourcehut_setup.md)
|
||||
|
|
|
|||
|
|
@ -4,69 +4,71 @@ Hausaufgaben A1 bis 28.3.:
|
|||
|
||||
## Software
|
||||
|
||||
Welche Programme verwenden Sie typischerweise für Ihre tägliche Arbeit auf Ihrem Rechner?
|
||||
Welche Programme verwenden Sie typischerweise für Ihre tägliche Arbeit auf Ihrem
|
||||
Rechner?
|
||||
|
||||
Stellen Sie die Programme mit ihrer Lizenz in einer Tabelle zusammen.
|
||||
|
||||
| Kategorie | Name | Lizenz |
|
||||
| ------------------- | ------------------- | ------------------------------------------------------------ |
|
||||
| Kategorie | Name | Lizenz |
|
||||
| ------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Betriebssystem | Debian | Kernel: GPLv2<br />Pakete: hauptsächlich freie Lizenzen<br />einige proprietäre Pakete im nonfree-Repository, bspw. `firmware-amd-graphics` (Lizenz: `binary-redist-AMD-restrictive`) |
|
||||
| Desktop Environment | KDE Plasma | GPL, LGPL |
|
||||
| Browser | Firefox | MPL (Mozilla Public License) |
|
||||
| IDE | VSCodium | MIT |
|
||||
| IDE | IntelliJ/PyCharm | Community-Version: Apache 2.0, Ultimate-Version: JetBrains User Agreement |
|
||||
| Markdown-Editor | Typora | Typora End User License Agreement |
|
||||
| Notizen | Joplin | AGPL 3.0 |
|
||||
| Git-Hosting | Gitea | MIT |
|
||||
| Git-Hosting | Gitlab | Community Edition: MIT, Enterprise Edition: GitLab Enterprise Edition (EE) license, source-available |
|
||||
| Bildbearbeitung | GIMP | GPLv3 |
|
||||
| 3D-Druck | PrusaSlicer | AGPL 3.0 |
|
||||
| Platinendesign | KiCad | GPLv3 |
|
||||
| 3D-Modellierung | Autodesk Fusion 360 | Autodesk License and Services Agreement |
|
||||
| Mediaplayer | VLC | GPLv2 |
|
||||
| Mediaserver | Jellyfin | GPLv2 |
|
||||
| Mediacenter | Kodi | GPLv2 |
|
||||
| Audiobook-Server | Audiobookshelf | GPLv3 |
|
||||
| YouTube-Client | NewPipe | GPLv3 |
|
||||
| Instant-Messaging | Signal | GPLv3 (Desktop-Version: AGPL 3.0) |
|
||||
| Online-Ausweis | AusweisApp | EUPL (Open Source Lizenz für die Europäische Union) |
|
||||
|
||||
|
||||
| Desktop Environment | KDE Plasma | GPL, LGPL |
|
||||
| Browser | Firefox | MPL (Mozilla Public License) |
|
||||
| IDE | VSCodium | MIT |
|
||||
| IDE | IntelliJ/PyCharm | Community-Version: Apache 2.0, Ultimate-Version: JetBrains User Agreement |
|
||||
| Markdown-Editor | Typora | Typora End User License Agreement |
|
||||
| Notizen | Joplin | AGPL 3.0 |
|
||||
| Git-Hosting | Gitea | MIT |
|
||||
| Git-Hosting | Gitlab | Community Edition: MIT, Enterprise Edition: GitLab Enterprise Edition (EE) license, source-available |
|
||||
| Bildbearbeitung | GIMP | GPLv3 |
|
||||
| 3D-Druck | PrusaSlicer | AGPL 3.0 |
|
||||
| Platinendesign | KiCad | GPLv3 |
|
||||
| 3D-Modellierung | Autodesk Fusion 360 | Autodesk License and Services Agreement |
|
||||
| Mediaplayer | VLC | GPLv2 |
|
||||
| Mediaserver | Jellyfin | GPLv2 |
|
||||
| Mediacenter | Kodi | GPLv2 |
|
||||
| Audiobook-Server | Audiobookshelf | GPLv3 |
|
||||
| YouTube-Client | NewPipe | GPLv3 |
|
||||
| Instant-Messaging | Signal | GPLv3 (Desktop-Version: AGPL 3.0) |
|
||||
| Online-Ausweis | AusweisApp | EUPL (Open Source Lizenz für die Europäische Union) |
|
||||
|
||||
## Geschichte freier Software
|
||||
|
||||
Ergänzen Sie die Geschichte freier Software (<https://www.kritische-informatik.de/index.htm?fshistl.htm> siehe oben) ab 2000. Recherchieren Sie selber, welche wichtigen Ereignisse in den letzten 20 Jahren Open-Source Geschichte stattgefunden haben.
|
||||
Ergänzen Sie die Geschichte freier Software
|
||||
(<https://www.kritische-informatik.de/index.htm?fshistl.htm> siehe oben) ab 2000.
|
||||
Recherchieren Sie selber, welche wichtigen Ereignisse in den letzten 20 Jahren
|
||||
Open-Source Geschichte stattgefunden haben.
|
||||
|
||||
| Jahr | Ereignisse |
|
||||
| ---- | ------------------------------------------------------------ |
|
||||
| 2001 | Linux 2.4, VLC, BitTorrent |
|
||||
| 2002 | Kodi (damals Xbox Media Player, später XBMC), Arch Linux |
|
||||
| 2003 | Linux 2.6 |
|
||||
| 2004 | NGINX 0.1.0, Ubuntu 4.10 |
|
||||
| 2005 | Git |
|
||||
| 2006 | Linux Mint, qBittorrent |
|
||||
| 2007 | GPLv3 |
|
||||
| 2008 | GitHub |
|
||||
| 2009 | Golang |
|
||||
| 2010 | F-Droid |
|
||||
| 2011 | Linux 3.0, GitLab |
|
||||
| 2012 | OctoPrint |
|
||||
| 2013 | Docker |
|
||||
| 2014 | Signal, Kubernetes, Heartbleed |
|
||||
| 2015 | Linux 4.0, Rust 1.0, NewPipe, VS Code |
|
||||
| 2016 | Gitea (Gogs-Fork), Mastodon |
|
||||
| 2017 | WebAssembly |
|
||||
| Jahr | Ereignisse |
|
||||
| ---- | ---------------------------------------------------------------------- |
|
||||
| 2001 | Linux 2.4, VLC, BitTorrent |
|
||||
| 2002 | Kodi (damals Xbox Media Player, später XBMC), Arch Linux |
|
||||
| 2003 | Linux 2.6 |
|
||||
| 2004 | NGINX 0.1.0, Ubuntu 4.10 |
|
||||
| 2005 | Git |
|
||||
| 2006 | Linux Mint, qBittorrent |
|
||||
| 2007 | GPLv3 |
|
||||
| 2008 | GitHub |
|
||||
| 2009 | Golang |
|
||||
| 2010 | F-Droid |
|
||||
| 2011 | Linux 3.0, GitLab |
|
||||
| 2012 | OctoPrint |
|
||||
| 2013 | Docker |
|
||||
| 2014 | Signal, Kubernetes, Heartbleed |
|
||||
| 2015 | Linux 4.0, Rust 1.0, NewPipe, VS Code |
|
||||
| 2016 | Gitea (Gogs-Fork), Mastodon |
|
||||
| 2017 | WebAssembly |
|
||||
| 2018 | GitHub von Microsoft übernommen, Jellyfin (Fork von Emby), ActivityPub |
|
||||
| 2019 | Linux 5.0 |
|
||||
| 2020 | Linux-Marktanteil > 3% |
|
||||
| 2021 | Log4j vulnerability, Audiobookshelf 1.0 |
|
||||
| 2022 | Linux 6.0, Forgejo (Gitea-Fork), Internet Explorer EOL |
|
||||
| 2019 | Linux 5.0 |
|
||||
| 2020 | Linux-Marktanteil > 3% |
|
||||
| 2021 | Log4j vulnerability, Audiobookshelf 1.0 |
|
||||
| 2022 | Linux 6.0, Forgejo (Gitea-Fork), Internet Explorer EOL |
|
||||
|
||||
## Videos
|
||||
|
||||
### 4 Freedoms
|
||||
|
||||
http://www.youtube.com/watch?v=uJi2rkHiNqg
|
||||
http://www.youtube.com/watch?v=uJi2rkHiNqg
|
||||
|
||||
Richard Stallman erklärt die 4 Freiheiten von Freier Software
|
||||
|
||||
|
|
@ -79,26 +81,29 @@ Richard Stallman erklärt die 4 Freiheiten von Freier Software
|
|||
|
||||
https://www.youtube.com/c/FreeSoftwareFoundationEurope
|
||||
|
||||
Werbevideo der Free Software Foundation Europe, erklärt die oben genannten 4 Freiheiten und geht darauf ein, dass freie Software immer wichtiger wird, je mehr Lebensbereiche von Computern bestimmt werden.
|
||||
Werbevideo der Free Software Foundation Europe, erklärt die oben genannten 4 Freiheiten
|
||||
und geht darauf ein, dass freie Software immer wichtiger wird, je mehr Lebensbereiche
|
||||
von Computern bestimmt werden.
|
||||
|
||||
### Das Microsoft-Dilemma
|
||||
|
||||
https://hhoegl.informatik.hs-augsburg.de/oss/ss20/Das-Microsoft-Dilemma-2018.mp4
|
||||
|
||||
Die Dokumentation beschreibt die Problematik der Verwendung proprietärer Software im öffentlichen
|
||||
Dienst.
|
||||
Die Dokumentation beschreibt die Problematik der Verwendung proprietärer Software im
|
||||
öffentlichen Dienst.
|
||||
|
||||
Die großflächige Verwendung nicht auditierbarer Software schafft Sicherheitslücken und ermöglicht
|
||||
die Verbeitung von Viren wie der WannaCry-Ransomware. Zudem macht sich unser Staat so von
|
||||
ausländischen Konzernen abhängig.
|
||||
Die großflächige Verwendung nicht auditierbarer Software schafft Sicherheitslücken und
|
||||
ermöglicht die Verbeitung von Viren wie der WannaCry-Ransomware. Zudem macht sich unser
|
||||
Staat so von ausländischen Konzernen abhängig.
|
||||
|
||||
Es wird kritisiert, dass es keine fairen Ausschreibungen zur Wahl des Softwarepakets für Behörden
|
||||
gibt, sondern die Verwendung von Microsoft-Produkten von Anfang an fest steht.
|
||||
Es wird kritisiert, dass es keine fairen Ausschreibungen zur Wahl des Softwarepakets für
|
||||
Behörden gibt, sondern die Verwendung von Microsoft-Produkten von Anfang an fest steht.
|
||||
|
||||
Es wird festgestellt, das die Verbeitung von Microsoft-Software viel mit Lobbyismus und
|
||||
Parteipolitik und wenig mit technischen Vorteilen dieser Software zu tun hat.
|
||||
|
||||
Als Beispiel wird die Münchener Stadtverwaltung genannt, die ihre IT auf Linux umgestellt hat. 2017
|
||||
wurde diese Umstellung nach einem Wechsel des Oberbürgermeisters wieder rückgängig gemacht. Es gibt
|
||||
Spekulationen, dass dies mit dem Umzug der Zentrale von Microsoft Deutschland nach München und dem
|
||||
stärkeren Einfluss des Konzerns zu tun hat.
|
||||
Als Beispiel wird die Münchener Stadtverwaltung genannt, die ihre IT auf Linux
|
||||
umgestellt hat. 2017 wurde diese Umstellung nach einem Wechsel des Oberbürgermeisters
|
||||
wieder rückgängig gemacht. Es gibt Spekulationen, dass dies mit dem Umzug der Zentrale
|
||||
von Microsoft Deutschland nach München und dem stärkeren Einfluss des Konzerns zu tun
|
||||
hat.
|
||||
|
|
|
|||
|
|
@ -2,4 +2,40 @@
|
|||
|
||||
Hausaufgaben A2 bis 03.4.:
|
||||
|
||||
## Unix-Geschichte
|
||||
|
||||
Bell Labs entwickelt zusammen mit dem MIT und General Electric ein
|
||||
Mainframe-Betriebssystem namens Multics.
|
||||
|
||||
**1969** Ken Thompson, der an Multics gearbeitet hatte, entschließt sich dazu, sein
|
||||
eigenes Betriebsssytem zu entwickeln. Das neue Betriebssystem wurde Unix genannt, da es
|
||||
deutlich kleiner und einfacher als Multics war. Entwickelt wurde es auf dem Minicomputer
|
||||
[PDP-7]([PDP-7 - Wikipedia](https://en.wikipedia.org/wiki/PDP-7)).
|
||||
|
||||
**1974** Thompson und Ritchie veröfffentlichten einen Artikel über Unix und stellten den
|
||||
Quellcode der nun fünften Version frei zur Verfügung. Unix stieß bei Universitäten auf
|
||||
großes Interesse, sodass einige von ihnen an eigenen Versionen des Projekts arbeiteten.
|
||||
Beispielsweise veröffentlichte die University of California in Berkley 1979 die
|
||||
BSD-Version von Unix.
|
||||
|
||||
**1978** Unix wird das erste Betriebssystem, das für 32bit-Rechnerarchitekturen
|
||||
verfügbar ist.
|
||||
|
||||
**1983** AT&T veröffentlicht die kommerzielle Unix-Version SystemV, nach dem sie als
|
||||
Nachfolger der Bell Labs das Projekt übernommen hatten.
|
||||
|
||||
**1984** Siemens veröffentlicht die Unix-Variante SINIX.
|
||||
|
||||
**1986** Der POSIX (Portable Operating System based on UNIX) Standard wird etabliert.
|
||||
POSIX spezifiziert die Programmierschnittstelle zwichen Betriebssystem und Anwendungen
|
||||
und sorgt dafür, dass die verschiedenen Unix-Derivate miteinander kompatibel sind.
|
||||
|
||||
**1992** GNU/Linux wird veröffentlicht.
|
||||
|
||||
**2000** Apple veröffentlicht das Open Source-Betriebssystem Darwin, basierend auf
|
||||
NeXTSTEP, BSD und dem Mach Kernel. Das Betriebssystem wird zur Grundlage von Apple's
|
||||
proprietären Betriebssystemen macOS und iOS.
|
||||
|
||||
### Quellen
|
||||
|
||||
- Geschichte des Unix-Systems <https://www.linux-praxis.de/geschichte-des-unix-systems>
|
||||
|
|
|
|||
|
|
@ -1,103 +1,184 @@
|
|||
# Aufgabe 3
|
||||
|
||||
Hausaufgaben A2 bis 11.4.:
|
||||
|
||||
## Code-Reading: Jellyfin
|
||||
|
||||
Was steht in der README.md?
|
||||
|
||||
> - Kurze Bescheibung des Projekts
|
||||
> - Links zur Dokumentationsseite
|
||||
> - Übersetzungsstatus
|
||||
> - Anleitung zum Aufsetzen der Entwicklungsumgebung
|
||||
|
||||
|
||||
Projekt aktiv oder verwaist? Wie aktiv war es in letzter Zeit?
|
||||
|
||||
> Jellyfin wird aktiv entwickelt, der letzte Commit ist unter 24 Stunden alt.
|
||||
|
||||
Wer hat es sich ursprünglich ausgedacht?
|
||||
> Jellyfin ist ein Fork des Emby Media Servers unter der Leitung von
|
||||
> Joshua Boniface.
|
||||
|
||||
> Jellyfin ist ein Fork des Emby Media Servers unter der Leitung von Joshua Boniface.
|
||||
|
||||
Wer ist der aktuelle Maintainer?
|
||||
|
||||
> Joshua Boniface
|
||||
|
||||
Wo wird das Projekt gehostet? (z.B. Github, Gitlab, Savannah https://savannah.gnu.org)
|
||||
<https://github.com/jellyfin/jellyfin>
|
||||
|
||||
Gibt es eine Homepage?
|
||||
<https://jellyfin.org/>
|
||||
Gibt es eine Homepage? <https://jellyfin.org/>
|
||||
|
||||
Für welche Betriebssysteme ist es geeignet?
|
||||
> Server: Linux, Windows, MacOS
|
||||
> Client: Web, Linux, Windows, MacOS, Android, iOS, Roku
|
||||
|
||||
> Server: Linux, Windows, MacOS Client: Web, Linux, Windows, MacOS, Android, iOS, Roku
|
||||
|
||||
Unter welcher Lizenz steht das Programm?
|
||||
|
||||
> GPL 2.0
|
||||
|
||||
Ist es ein Kommandozeilen- oder Grafikprogramm?
|
||||
|
||||
> Jellyfin Server ist eine Webanwendung.
|
||||
|
||||
Wie lange existiert es?
|
||||
> Emby existiert seit 2015, der Fork Jellyfin wurde 2018 als Reaktion auf die Veröffentlichung von Emby 4 unter einer proprietären Lizenz erstellt.
|
||||
|
||||
> Emby existiert seit 2015, der Fork Jellyfin wurde 2018 als Reaktion auf die
|
||||
> Veröffentlichung von Emby 4 unter einer proprietären Lizenz erstellt.
|
||||
|
||||
Wie viele haben in etwa daran gearbeitet?
|
||||
|
||||
> 880 Beitragende für das Backend, 1300 Beitragende für die Web-UI
|
||||
|
||||
Welche Programmiersprache(n) wird/werden verwendet? (Tipp: https://github.com/XAMPPRocky/tokei)
|
||||
Welche Programmiersprache(n) wird/werden verwendet? (Tipp:
|
||||
https://github.com/XAMPPRocky/tokei)
|
||||
|
||||
> Backend: C#, Frontend: Javascript/Typescript
|
||||
|
||||
Welches Konfigurations- bzw. Build-System wird verwendet?
|
||||
|
||||
> Backend: dotnet SDK, Frontend: webpack
|
||||
|
||||
Wird eine IDE zum Entwickeln verwendet?
|
||||
|
||||
> Visual Studio Code, JetBrains ReSharper
|
||||
|
||||
Gibt es eine Dokumentation, wenn ja, in welchem Textverarbeitungssystem wurde sie geschrieben?
|
||||
> Ja, die Dokumentationsseite (<https://jellyfin.org>) ist in Markdown geschrieben und wird mit Docusaurus gebaut.
|
||||
Gibt es eine Dokumentation, wenn ja, in welchem Textverarbeitungssystem wurde sie
|
||||
geschrieben?
|
||||
|
||||
> Ja, die Dokumentationsseite (<https://jellyfin.org>) ist in Markdown geschrieben und
|
||||
> wird mit Docusaurus gebaut.
|
||||
|
||||
Wie viele Anwender verwenden das Programm ungefähr? (schwer herauszubekommen)
|
||||
> Jellyfin beinhaltet keine Telemetrie, deswegen gibt es keine Nutzerzahlen. Stattdessen habe ich andere andere Metriken zur Beliebtheit des Projekts aufgelistet:
|
||||
|
||||
> Jellyfin beinhaltet keine Telemetrie, deswegen gibt es keine Nutzerzahlen. Stattdessen
|
||||
> habe ich andere andere Metriken zur Beliebtheit des Projekts aufgelistet:
|
||||
>
|
||||
> - 22k Stars auf Github
|
||||
> - 200M Pulls auf Docker
|
||||
> - das Jellyfin-Subreddit hat 45k Mitglieder
|
||||
|
||||
Gibt es Abspaltungen ("forks")?
|
||||
> Jellyfin stellt einen Fork des Emby Media Servers dar. Von Jellyfin selbst gibt es keine nennenswerten Forks. Es gibt jedoch ein Pluginsystem, um fehlende Features hinzuzufügen (bspw. weitere Datenquellen, LDAP-Authentifizierung, Vorspann von Serien automatisch überspringen etc.)
|
||||
|
||||
> Jellyfin stellt einen Fork des Emby Media Servers dar. Von Jellyfin selbst gibt es
|
||||
> keine nennenswerten Forks. Es gibt jedoch ein Pluginsystem, um fehlende Features
|
||||
> hinzuzufügen (bspw. weitere Datenquellen, LDAP-Authentifizierung, Vorspann von Serien
|
||||
> automatisch überspringen etc.)
|
||||
|
||||
Wie kann man mitmachen bzw. Änderungen einreichen?
|
||||
|
||||
> - Übersetzungen können auf einer projekteigenen Weblate-Instanz eingegeben werden
|
||||
> - Codeänderungen werden über Pull Requests auf GitHub entgegengenommen
|
||||
|
||||
Wie werden Branches in Git verwendet? (git Workflow bei der Entwicklung)
|
||||
> - Änderungen von Teammitgliedern werden in eigenen Feature-Branches geführt und anschließend in den Master-Branch gemerged.
|
||||
|
||||
> - Änderungen von Teammitgliedern werden in eigenen Feature-Branches geführt und
|
||||
> anschließend in den Master-Branch gemerged.
|
||||
> - Für jedes Feature-Release wird ein eigener Branch angelegt (z.B. `release-10.8.z`).
|
||||
|
||||
Wie kann man das Programm installieren? (selber kompilieren, binary, snap, appimage, container, ...)
|
||||
Wie kann man das Programm installieren? (selber kompilieren, binary, snap, appimage,
|
||||
container, ...)
|
||||
|
||||
> - Selbst mit dotnet SDK und webpack kompilieren
|
||||
> - Binary (Download von der Webseite)
|
||||
> - deb/rpm-Package von Jellyfin's eigenem Repository
|
||||
> - Container: offizielle Version von Jellyfin (`jellyfin/jellyfin`), linuxserver.io-Version (`linuxserver/jellyfin`)
|
||||
> - Container: offizielle Version von Jellyfin (`jellyfin/jellyfin`),
|
||||
> linuxserver.io-Version (`linuxserver/jellyfin`)
|
||||
|
||||
In welcher Sprache sind die Meldungen des Programms verfasst, z.B. Englisch, Deutsch, Chinesisch? Gibt es eine Internationalisierung in verschiedenen Sprachen (z.B. GNU gettext)?
|
||||
> Jellyfin ist in 84 Sprachen übersetzt. Die Internationalisierung wurde mit JSON-Dateien realisiert, auf eine spezielle Library wie gettext wurde verzichtet.
|
||||
> Übersetzungen können auf einer eigenen Weblate-Instanz vorgenommen werden und werden automatisch in die Repositories eingepflegt.
|
||||
In welcher Sprache sind die Meldungen des Programms verfasst, z.B. Englisch, Deutsch,
|
||||
Chinesisch? Gibt es eine Internationalisierung in verschiedenen Sprachen (z.B. GNU
|
||||
gettext)?
|
||||
|
||||
> Jellyfin ist in 84 Sprachen übersetzt. Die Internationalisierung wurde mit
|
||||
> JSON-Dateien realisiert, auf eine spezielle Library wie gettext wurde verzichtet.
|
||||
> Übersetzungen können auf einer eigenen Weblate-Instanz vorgenommen werden und werden
|
||||
> automatisch in die Repositories eingepflegt.
|
||||
|
||||
## Projekte und Organisationen mit Open- im Namen
|
||||
|
||||
- OpenStreetMap (Durch Crowdsourcing erstellte Weltkarte unter der Open Database License)
|
||||
- Open Office (freie Office-Suite, aktuell als Fork *LibreOffice* weitergeführt)
|
||||
- OpenStreetMap (Durch Crowdsourcing erstellte Weltkarte unter der Open Database
|
||||
License)
|
||||
- Open Office (freie Office-Suite, aktuell als Fork _LibreOffice_ weitergeführt)
|
||||
- OpenGL (Plattformunabhängige Grafikbibliothek)
|
||||
- OpenSearch (von AWS entwickelter Fork von ElaticSearch nach deren Wechsel zur SSPL Lizenz)
|
||||
- OpenAI (bis auf wenige Ausnahmen wie Whisper ist deren Software proprietär, der Name deswegen irreführend)
|
||||
|
||||
- OpenSearch (von AWS entwickelter Fork von ElasticSearch nach deren Wechsel zur SSPL
|
||||
Lizenz)
|
||||
- OpenAI (bis auf wenige Ausnahmen wie Whisper ist deren Software proprietär, der Name
|
||||
deswegen irreführend)
|
||||
|
||||
## Freemium
|
||||
|
||||
Freemium ist ein Kofferwort aus den Begriffen "Free" und "Premium" und bezeichnet ein kostenfreies nutzbares Produkt, das mit kostenpflichtigen Angeboten aufgewertet werden kann.
|
||||
Freemium ist ein Kofferwort aus den Begriffen "Free" und "Premium" und bezeichnet ein
|
||||
kostenfreies nutzbares Produkt, das mit kostenpflichtigen Angeboten aufgewertet werden
|
||||
kann.
|
||||
|
||||
Dieses Geschäftsmodell ist bei Software sehr beliebt, da viele Nutzer nicht dazu bereit sind, initial für Software zu bezahlen. Hat der Nutzer die Software jedoch in seinen Workflow oder sein Leben integriert, ist er viel eher dazu bereit, für mehr Features zu bezahlen.
|
||||
Dieses Geschäftsmodell ist bei Software sehr beliebt, da viele Nutzer nicht dazu bereit
|
||||
sind, initial für Software zu bezahlen. Hat der Nutzer die Software jedoch in seinen
|
||||
Workflow oder sein Leben integriert, ist er viel eher dazu bereit, für mehr Features zu
|
||||
bezahlen.
|
||||
|
||||
Das Freemium-Konzept existiert auch bei einigen kommerziellen Open-Source-Projekten. Hierbei wird die kostenfreie Basisanwendung unter einer Open Source Lizenz veröffentlicht, während der Quellcode für die kostenpflichtige Premiumversion entweder geschlossen bleibt oder unter einer proprietären Lizent veröffentlicht wird (source-available).
|
||||
Das Freemium-Konzept existiert auch bei einigen kommerziellen Open-Source-Projekten.
|
||||
Hierbei wird die kostenfreie Basisanwendung unter einer Open Source Lizenz
|
||||
veröffentlicht, während der Quellcode für die kostenpflichtige Premiumversion entweder
|
||||
geschlossen bleibt oder unter einer proprietären Lizent veröffentlicht wird
|
||||
(source-available).
|
||||
|
||||
Zu den kostenpflichtigen Features gehörten oft solche Features, die vorwiegend von Unternehmen eingesetzt werden (bspw. Single Sign On oder eine erweiterte Benutzerrechteverwaltung).
|
||||
Zu den kostenpflichtigen Features gehörten oft solche Features, die vorwiegend von
|
||||
Unternehmen eingesetzt werden (bspw. Single Sign On oder eine erweiterte
|
||||
Benutzerrechteverwaltung).
|
||||
|
||||
Beispiele für Freemium-Open-Source-Projekte sind JetBrains IntelliJ/PyCharm sowie Gitlab.
|
||||
Beispiele für Freemium-Open-Source-Projekte sind JetBrains IntelliJ/PyCharm sowie
|
||||
Gitlab.
|
||||
|
||||
## Lizenz-Quiz
|
||||
|
||||
1. Welche Open-Source-Lizenz verlangt, dass Code auf private oder akademische Projekte
|
||||
beschränkt bleibt? `Keine`
|
||||
2. Bei welcher Lizenz muss das ganze Programm unter dieser Lizenz veröffentlicht werden,
|
||||
wenn so lizenzierter Code eingebettet wird? `GPL und MPL`
|
||||
3. Falls Open Source ein Patent verletzt, gegen wen kann der Patenteigentümer Ansprüche
|
||||
geltend machen? `Entwickler und Integratoren`
|
||||
4. Welche der Open-Source-Lizenzen verlangt, dass solchen Code enthaltenden Produkte den
|
||||
Lizenztext mit ausliefern? `GPL, BSD und MPL`
|
||||
5. Jemand veröffentlicht ein Code-Snippet. Unter welchen Umständen kann ein Dritter das
|
||||
Snippet gefahrlos integrieren?
|
||||
`Wenn der Veröffentlicher explizit auf die Lizenz hinweist`
|
||||
|
||||
## Artikel: Steuermillionen für Hobbyprojekte
|
||||
|
||||
- Das Projekt "Sovereign Tech Fund" fördert ausgewählte Open-Source-Projekte
|
||||
- STF erhielt bis Ende 2023 13 Millionen Euro vom Wirtschaftsministerium
|
||||
- Webseite des Projekts: <https://sovereigntechfund.de>
|
||||
- Geförderte Projekte:
|
||||
- RubyGems (Paketmanager für Ruby)
|
||||
- OpenBGPd (offene Implementation des Border Gateway Protocol für Internetrouter)
|
||||
- OpenSSH (Tool zur Fernsteuerung und zum Datenaustausch mit anderen Rechnern im
|
||||
Netzwerk)
|
||||
- curl (HTTP-Client)
|
||||
- OpenMLS (Library für End2End-verschlüsselte Nachrichtenübertragung)
|
||||
- Sequoia PGP (Rust-Implementierung der PGP-Verschlüsselungssoftware)
|
||||
- OpenPGP.js (Javascript-Implementierung der PGP-Verschlüsselungssoftware)
|
||||
- Fortran Package Manager
|
||||
- WireGuard (VPN-Software)
|
||||
- Es wurden keine innovativen Prestigeprojekte gefördert, sondern Projekte, die wichtige
|
||||
Bestandteile von IT-Infrastruktur darstellen.
|
||||
- Mangelnde Pflege dieser Komponenten kann zu flächendeckender Verwundbarkeit von
|
||||
IT-Systemen führen, was durch die Log4Shell-Vulnerability deutlich wurde.
|
||||
|
|
|
|||
38
src/aufgaben/aufgabe_4.md
Normal file
38
src/aufgaben/aufgabe_4.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# Aufgabe 4
|
||||
|
||||
Hausaufgaben A4 bis 18.4.:
|
||||
|
||||
## Debian-Begriffe
|
||||
|
||||
- Debian wurde von Ian Murdock (1973-2015) entwickelt
|
||||
- Die erste Version wurde 1993 veröffentlicht
|
||||
- Benannt nach dem Entwickler und seiner Frau Debby
|
||||
- Debian-Philosophie: die Mission, ein freies Betriebssystem zu erschaffen
|
||||
- Debians Definition freier Software
|
||||
- Software muss ohne Beschränkungen verkauft oder verbreitet werden dürfen
|
||||
- Quellcode muss verfügbar sein
|
||||
- Modifikationen müssen unter der gleichen Lizenz verbreitet werden dürfen
|
||||
- Personen, Personengruppen oder Einsatzzwecke dürfen nicht ausgeschlossen werden
|
||||
- Unfreie Software (z.B. proprietäre Treiber) wird in einem separaten Repository
|
||||
bereitgestellt.
|
||||
- Offiziell unterstützte Architekturen: amd64 (64bit Intel/AMD), i368, arm64 (64bit
|
||||
ARM), armel, armhf (32bit ARM +FPU), mips64el, mipsel, ppc64el (64bit PowerPC), s390x
|
||||
(IBM System Z Mainframes)
|
||||
- 3 Repositories: main, non-free (Pakete, die nicht unter Debians Definition freier
|
||||
Software fallen), contrib (Pakete, die von unfreien Paketen abhängen)
|
||||
- 3 Branches: stable, testing, unstable (sid)
|
||||
- Paket-Zyklus: upstream -> package -> incoming -> unstable -> testing -> frozen ->
|
||||
stable
|
||||
- Debian ist Grundlage von vielen Linux-Distributionen: Knoppix, Ubuntu, Mint,
|
||||
Siduction, grml.org, Emmabuntüs, Kali, Steam OS, gparted
|
||||
- <https://screenshots.debian.net>: Archiv für Screenshots von Debian-Anwendungen
|
||||
- Beitragen: <https://debian.org/devel/join>
|
||||
- Dachorganisation: Software in the Public Interest (SPI)
|
||||
- GFDL-Problem: die GNU Free Documentation License erfüllt Debian's Anforderungen für
|
||||
freie Software nicht, da sie erlaubt, bestimmte Teile der Dokumentation als
|
||||
unveränderlich zu markieren. Deswegen musste die Dokumentation einiger Software aus
|
||||
den Paketen entfernt und in das nonfree-Repository verschoben werden.
|
||||
- Popularity Contest: ein kleines Programm, das anonyme Statistiken über installierte
|
||||
Pakete veröffentlicht. Die Statistiken sind über <https://popcon.debian.org> abrufbar.
|
||||
- Netinst: Minimales Debian-Installationsimage (150-300MB groß). Zur Installation einer
|
||||
Desktop-Umgebung müssen weitere Pakete über das Internet heruntergeladen werden.
|
||||
63
src/aufgaben/aufgabe_5.md
Normal file
63
src/aufgaben/aufgabe_5.md
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
# Aufgabe 5
|
||||
|
||||
Hausaufgaben A4 bis 2.5.:
|
||||
|
||||
## Firmen beim Linux Infotag 2023
|
||||
|
||||
- **SUSE** Linux-Support für Unternehmen
|
||||
- **IGEL Technology GmbH** Entwicklung eines kommerziellen Betriebssystems auf
|
||||
Linux-Basis für Arbeitsplatzrechner
|
||||
- **makandra GmbH** Individualentwicklung von Webanwendungen (hauptsächlich mittels Ruby
|
||||
on Rails)
|
||||
- **TUXEDO Computers** Verkauf von Laptops und PCs mit vorinstalliertem
|
||||
Linux-Betriebssystem
|
||||
|
||||
## Open Data
|
||||
|
||||
Staatliche Institutionen sammeln und pflegen eine Vielzahl von Daten über das Land und
|
||||
seine Bürger. Während diese Arbeit mit Steuermitteln finanziert wird, sind die Daten oft
|
||||
nur für Behördenmitarbeiter und nicht für die Allgemeinheit nutzbar.
|
||||
|
||||
Open Data ist das Konzept, diese Daten unter einer freien Lizenz im Internet verfügbar
|
||||
zu machen, sodass Unternehmen, Forscher und Privatpersonen die Daten in ihre eigenen
|
||||
Anwendungen integrieren können.
|
||||
|
||||
Auch viele Unternehmen und Nichtregierungsorganisationen veröffentlichen Teile ihres
|
||||
Datenbestandes. Dies kann auch wirtschaftliche Vorteile für das Unternehmen bieten,
|
||||
beispielsweise die Förderund der Forschung an für das Unternehmen relevaten
|
||||
Technologien.
|
||||
|
||||
Beispielsweise veröffentlicht die Deutsche Bahn Daten über alle ihre Bahnhöfe und
|
||||
Haltestellen unter der CC BY 4.0-Lizenz.
|
||||
|
||||
Die Stadt Köln veröffentlicht seit 2010 Listen mit allen im jeweiligen Jahr vergebenen
|
||||
Vornamen unter der
|
||||
"[Datenlizenz Deutschland – Zero](https://www.govdata.de/dl-de/zero-2-0)" (ähnlich der
|
||||
CC0-Lizenz).
|
||||
|
||||
## Make a Difference Without Making a Pull Request
|
||||
|
||||
Der Autor listet verschiedene Wege auf, an einem Open-Source-Projekt mitzuarbeiten, ohne
|
||||
Code beizutragen.
|
||||
|
||||
1. Andere Beiträge (Pull-Requests) überprüfen
|
||||
|
||||
- Die Pull-Request testen und prüfen, ob der Fix/das neue Feature funktioniert
|
||||
- Neuen Code und Dokumentationstext lesen und auf Fehler überprüfen
|
||||
|
||||
2. Das Projekt testen
|
||||
|
||||
- Die Software nutzen, Fehler dokumentieren und Issues erstellen
|
||||
- Dokumentation korrekturlesen
|
||||
- Accessibility sicherstellen
|
||||
|
||||
3. Issues triagieren
|
||||
|
||||
- Mit dem Ersteller kommunizieren und eventuelle Missverständnisse und fehlende
|
||||
Informationen klären
|
||||
- Prüfen, ob der Ersteller die aktuelle Version verwendet
|
||||
- Auf Duplikate prüfen
|
||||
- Das Issue korrekt benennen und formatieren
|
||||
- Kategorisieren (Bug, Feature request, Spam, etc...)
|
||||
- Für Bugs: nach einer Anleitung zum Reproduzieren fragen und selbst versuchen, den Bug
|
||||
zu reproduzieren
|
||||
161
src/studienarbeit/1_einleitung.md
Normal file
161
src/studienarbeit/1_einleitung.md
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
# Selfhosting von Open-Source-Entwicklertools
|
||||
|
||||
Um effizient mit anderen Entwicklern an Open-Source-Projekten arbeiten zu können, muss
|
||||
man den Quellcode seines Projekts veröffentlichen, Aufgaben koordinieren und neue
|
||||
Codebeiträge entgegen nehmen.
|
||||
|
||||
Hierbei kommt fast immer eine Git-Hosting-Plattform zum Einsatz. Diese erlaubt es einem,
|
||||
sein Repository zu veröffentlichen und mit anderen Personen über das Internet
|
||||
zusammenzuarbeiten. Andere Nutzer und Entwickler können Softwarefehler melden,
|
||||
Vorschläge für neue Features machen und neuen Code zum Projekt beitragen.
|
||||
|
||||
Der meistgenutzte Git-Hosting-Anbieter ist GitHub. Die Plattform wurde von Tom
|
||||
Preston-Werner, Chris Wanstrath, P. J. Hyett and Scott Chacon gegründet und ging 2008
|
||||
ans Netz. 2018 wurde die Firma von Microsoft übernommen.
|
||||
|
||||
Der große Vorteil von GitHub ist, dass der Dienst für öffentliche Projekte vollkommen
|
||||
kostenlos ist. Zudem hat der Dienst mit 100 Millionen Nutzern die mit Abstand größte
|
||||
Community an potenziellen Beitragenden.
|
||||
|
||||
GitHub bietet auch einen Continuous-Integration-Dienst namens GitHub Actions an, mit dem
|
||||
man sein Projekt automatisch testen und veröffentlichen lassen kann. Im Gegensatz zu
|
||||
vielen Konkurrenzanbietern setzt GitHub hierbei kein Nutzungslimit bei öffentlichen
|
||||
Repositories.
|
||||
|
||||
Allerdings hat die Nutzung von GitHub auch seine Nachteile. Zum einen ist man bei der
|
||||
Nutzung eines fremden Webdiensts, insbesondere wenn dieser kostenlos ist und man
|
||||
deswegen keinen Vertrag mit dem Anbieter abgeschlossen hat, komplett von dessen
|
||||
Entscheidungen und Nutzungsbedingungen abhängig. Der Anbieter kann den Dienst
|
||||
einstellen, kostenpflichtig machen, Features entfernen oder bestimmte Nutzer
|
||||
ausschließen.
|
||||
|
||||
Beispielsweise wurde der russische Webentwickler Nikolay Kuchumov wegen eines einzigen
|
||||
beleidigenden Issues
|
||||
[2020 auf GitHub gesperrt](https://medium.com/@catamphetamine/how-github-blocked-me-and-all-my-libraries-c32c61f061d3).
|
||||
Dabei wurden alle seine Repositories von der Plattform entfernt. Noch absurder: GitHub
|
||||
verlangte eine Kopie seines Personalausweis um die Sperre wieder aufzuheben.
|
||||
|
||||
Es gibt auch einige Fälle von Open Source-Projekten, die von GitHub wegen angeblichen
|
||||
Verstößen gegen das amerikanische Urheberrecht (DMCA) gesperrt wurden. Das prominenteste
|
||||
Beispiel hierfür ist der Video-Downloader
|
||||
[youtube-dl](github.blog/2020-11-16-standing-up-for-developers-youtube-dl-is-back/).
|
||||
Auch das Repository der alternativen Smartwatch-App
|
||||
[Gadgetbridge](https://www.heise.de/news/Pebble-Gadgetbridge-unter-Beschuss-3740625.html)
|
||||
wurde zeitweise von GitHub gesperrt. Eine selbstgehostete Plattform ist dagegen viel
|
||||
schwieriger zu sperren.
|
||||
|
||||
Ein weiterer Grund für einige Entwickler, die GitHub-Plattform zu verlassen, ist die
|
||||
Einführung von GitHub Copilot. Hierbei handelt es sich um ein künstliche Intelligenz,
|
||||
die einem Programmierer automatisch Code-Vorschläge geben kann. Dessen Sprachmodell
|
||||
wurde mit dem Code aus öffentlichen GitHub-Repositories trainiert. Kritiker sehen
|
||||
hierbei eine Urheberrechtsverletzung, da der AI-generierte Code Schnipsel aus den
|
||||
Trainingsdaten enthalten kann, die dann ohne Erwähnung des Urhebers in andere Projekte
|
||||
eingefügt werden.
|
||||
|
||||
Insbesondere bei privaten oder firmeninternen Projekten kann auch der Datenschutz ein
|
||||
Grund sein, auf Webanwendungen von Fremdanbietern zu verzichten und die Daten auf
|
||||
eigenen Servern zu speichern. Da GitHub nicht quelloffen ist und nur mit einer
|
||||
kostspieligen Enterprise-Lizenz selbst gehostet werden kann, ist is für solche Fälle
|
||||
attraktiv, eine Open-Source-Anwendung einzusetzen.
|
||||
|
||||
Mittlerweile gibt es mehrere Open-Source-Projekte, die Alternativen zu GitHub entwickelt
|
||||
hat. Im Gegensatz zu proprietären Webdiensten lassen sich diese Anwendungen auf eigenen
|
||||
Servern installieren, sodass man die volle Autonomie über sein System behält.
|
||||
|
||||
In dieser Arbeit werde ich vier von ihnen testen und vergleichen.
|
||||
|
||||
## Testkriterien
|
||||
|
||||
Ich habe jede Plattform auf meinem Rechner installiert und nach folgenden Kritierien
|
||||
getestet:
|
||||
|
||||
### 0\. Über das Projekt
|
||||
|
||||
Zuerst werde ich einige grundlegende Informationen über die entsprechende Anwendung
|
||||
präsentieren.
|
||||
|
||||
- In welcher Programmiersprache ist die Anwendung geschrieben?
|
||||
- Wie lange existiert das Projekt bereits? Ist es eine Abspaltung eines anderen
|
||||
Projekts?
|
||||
- Wie viele Beitragende hat das Projekt?
|
||||
- Wie sieht die Architektur der Anwendung aus? Welche Dienste werden benötigt?
|
||||
|
||||
### 1\. Installation und Einrichtung
|
||||
|
||||
Hier gebe ich eine kurze Anleitung zur Installation und Einrichtung der Anwendung. Ich
|
||||
werde hierbei bewerten, wie einfach die Installation vonstatten geht.
|
||||
|
||||
Monolithisch (d.h. aus einem Dienst) aufgebaute Anwendungen sind in der Regel einfacher
|
||||
einzurichten, bieten aber weniger Flexibilität bei der Skalierung für viele User.
|
||||
|
||||
### 2\. Systemanforderungen
|
||||
|
||||
Hierbei geht es nicht nur um die unterstützten Betriebssysteme und CPU-Architekturen,
|
||||
sondern auch um den Bedarf an Rechenleistung und Arbeitsspeicher. Im Idealfall soll die
|
||||
Software auch auf preisgünstigen Single Board-Computern und virtualisierten Servern
|
||||
lauffähig sein, sodass sich jeder ein selbst gehostetes Setup leisten kann und nicht aus
|
||||
Kostengründen auf proprietäre Anbieter angewiesen ist.
|
||||
|
||||
Getestet wurden CPU-Auslastung und Arbeitsspeicherverbrauch auf einem Rechner mit einem
|
||||
Ryzen 5700G-Prozessor (16 Threads) und 32GB RAM. Die angegebene CPU-Auslastung bezieht
|
||||
sich auf die ausgelasteten Threads (wie in htop angezeigt), d.h. 100% entspricht einem
|
||||
voll ausgelastetem Thread, 16.000% einem voll ausgelasteten Prozessor.
|
||||
|
||||
Neben dem Ressourcenverbrauch im Leerlauf habe ich auch die CPU-Auslastung unter Last
|
||||
gemessen. Hierfür habe ich das Repository des Linux-Kernels importiert und mir die
|
||||
Versionsgeschichte und die Blame-Ansicht der Makefile im Stammverzeichnis anzeigen
|
||||
lassen.
|
||||
|
||||
### 3\. Bedienung
|
||||
|
||||
Wie einfach ist die Weboberfläche zu bedienen? Ist es möglich, schnell durch
|
||||
Repositories zu navigieren? Gibt es eine Suchfunktion, um beispielsweise eine bestimmte
|
||||
Funktion im Code zu finden?
|
||||
|
||||
Zudem habe ich dir Unterstützung für verschiedene Dateiformate getestet. Alle
|
||||
Plattformen können Code, Markdown und Textdateien darstellen. Binärdateien können auf
|
||||
diese Weise natürlich nicht dargestellt werden, weswegen einige Plattformen spezielle
|
||||
Viewer für bestimmte Dateitypen mitbringen. Um dies zu testen, habe ich ein Repository
|
||||
mit Dateien in folgenden Formaten angelegt.
|
||||
|
||||
- Bilder (\*.jpg, \*.svg)
|
||||
- Tabellen (\*.csv, \*.xlsx, \*.ods)
|
||||
- Text (\*.rst, \*.tex, \*.docx, \*.odt)
|
||||
- PDF-Dokumente
|
||||
- 3D-Modelle (\*.stl)
|
||||
- Jupyter-Notebooks (\*.ipynb)
|
||||
|
||||
Zum Vergleich: GitHub unterstützt alle diese Dateitypen mit Ausnahme von LaTEX- und
|
||||
MS/Open Office-Dokumenten.
|
||||
|
||||
### 4\. Import bestehender Projekte
|
||||
|
||||
Eine gute GitHub-Alternative sollte es dem Entwickler ermöglichen, bestehende Projekte
|
||||
von anderen Providern zu importieren. Hierbei soll nicht nur das Repository, sondern
|
||||
auch z.B. Issues übertragen werden können.
|
||||
|
||||
### 5\. Zusatzfeatures
|
||||
|
||||
Bietet die Anwendung zusätzlich zu Git-Repositories, Issues und Pull-Requests noch
|
||||
weitere Features an?
|
||||
|
||||
Beispiele hierfür wären das Hosting von statischen Websites direkt aus Repositories
|
||||
heraus, ein Repository für Softwarepakete verschiedener Programmiersprachen oder
|
||||
Projektmanagement-Tools.
|
||||
|
||||
### 6\. Continuous Integration
|
||||
|
||||
Continuous Integration (CI), also das automatische Testen von neuem Code ist ein fester
|
||||
Teil des Worflows vieler Entwickler. Hat die Plattform einen CI-Dienst eingebaut oder
|
||||
lässt sie sich mit anderen CI-Diensten integrieren?
|
||||
|
||||
### 7\. Öffentliche Instanzen
|
||||
|
||||
Nicht jeder möchte den Aufwand betreiben, seine Git-Hosting-Plattform selbst zu hosten.
|
||||
Deswegen ist es vom Vorteil, wenn es die Möglichkeit gibt, anstelle dessen einer
|
||||
öffentlichen Instanz beizutreten.
|
||||
|
||||
## Quellen
|
||||
|
||||
- [Software Freedom Conservancy](https://sfconservancy.org/GiveUpGitHub/): Give up
|
||||
GitHub
|
||||
277
src/studienarbeit/2_gitlab.md
Normal file
277
src/studienarbeit/2_gitlab.md
Normal file
|
|
@ -0,0 +1,277 @@
|
|||
# GitLab
|
||||
|
||||
2011, drei Jahre nach dem Start von GitHub veröffentlichten Dmytro Zaporozhets und Sytse
|
||||
Sijbrandij die erste Version von GitLab. Damit ist GitLab die erste und bekannteste
|
||||
Open-Source-Alternative zu GitHub.
|
||||
|
||||
GitLab Community Edition ist unter der MIT-Lizenz veröffentlicht. Die Firma hinter
|
||||
GitLab verfolgt ein "Open Core"-Geschäftsmodell, d.h. einige fortgeschrittene Features
|
||||
sind nicht in der Community Edition enthalten und erfordern die proprietären Versionen
|
||||
"Premium" bzw. "Ultimate". Diese sind nur in Form eines Abonnements zum Preis von 29
|
||||
(Premium) bzw. 99USD (Ultimate) pro Nutzer und Monat erhältlich. Open-Source-Projekte
|
||||
und Bildungseinrichtungen können die Ultimate-Version kostenfrei nutzen.
|
||||
|
||||
Im Kern ist GitLab eine Ruby-on-Rails-Webanwendung. Allerdings sind einige Funktionen
|
||||
der Plattform (bspw. SSH oder Git-Operationen) an zusätzliche Services ausgelagert. Die
|
||||
meisten dieser Services sind in Go implementiert. Das Webfrontend wurde mit Vue.js
|
||||
implementiert.
|
||||
|
||||
<img src="./assets/gitlab/architecture.png" alt="GitLab Architektur" width="500"/>
|
||||
|
||||
- **Workhorse** Reverse Proxy, der HTTP-Anfragen an Git oder die Hauptanwendung
|
||||
weiterleitet
|
||||
- **Gitaly** Microservice zur Speicherung der Git-Repositories und Verarbeitung von
|
||||
Git-Anfragen
|
||||
- **GitLab Shell** SSH-Server
|
||||
- **Sidekiq** Task Queue zur Ausführung von Aufgaben im Hintergrund
|
||||
|
||||
GitLab verwendet eine PostgreSQL-Datenbank zur Speicherung seiner Daten. Zudem kommt
|
||||
eine Redis-Instanz als Cache und Event Queue zum Einsatz.
|
||||
|
||||
Getestet wurde GitLab in der Version 16.1.1.
|
||||
|
||||
## Installation
|
||||
|
||||
Um die Installation der Anwendung trotz ihres Aufbaus aus verschiedenen Services zu
|
||||
vereinfachen, stellt GitLab ein Omnibus-Paket zur verfügung. Hierbei handelt es sich um
|
||||
ein Linux-Softwarepaket, das die gesamte GitLab-Anwendung mit allen Services (inklusive
|
||||
NGINX, Redis und Postgres) beinhalten. Die Pakete sind für die meisten
|
||||
Linux-Distributionen (Ubuntu, Debian, Alma Linux, CentOS, OpenSUSE, Raspberry Pi OS)
|
||||
verfügbar.
|
||||
|
||||
Um Gitlab als Omnibus-Paket zu installieren, muss man zuerst das Gitlab-Repository zu
|
||||
seinem System hinzufügen. Hierfür kann man dieses Skript verwenden:
|
||||
<https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh>.
|
||||
|
||||
Danach kann man GitLab mit diesem Befehl installieren und starten:
|
||||
|
||||
```
|
||||
GITLAB_ROOT_PASSWORD="<strongpassword>" EXTERNAL_URL="http://gitlab.example.com" apt install gitlab-ce
|
||||
```
|
||||
|
||||
Der Konfigurationsprozess dauert mehrere Minuten. Wenn der Webserver gestartet ist, kann
|
||||
man die Weboberfläche aufrufen und sich anmelden (Benutzername: `root`).
|
||||
|
||||
GitLab stellt auch ein Docker-Image (`gitlab/gitlab-ce`) zur Verfügung, welches das
|
||||
Omnibus-Paket beinhaltet. Der Einrichtungsprozess ist der gleiche wie bei einer bare
|
||||
metal-Installation, mit dem Unterschied dass die Konfiguration durch die
|
||||
Umgebungsvariable `GITLAB_OMNIBUS_CONFIG` erfolgt.
|
||||
|
||||
[Hier](./assets/gitlab/docker-compose.yml) ist die Docker-Compose-Datei, die ich für
|
||||
meine Testinstallation verwendet habe.
|
||||
|
||||
Für Unternehmen und große Organisationen mit Tausenden Nutzern bietet GitLab in ihrer
|
||||
Dokumentation auch Referenzarchitekturen für hochverfügbare Systemen mit mehreren
|
||||
Servern.
|
||||
|
||||
## Systemanforderungen
|
||||
|
||||
GitLab bietet Pakete für eine
|
||||
[Vielzahl von Linux-Distributionen](https://docs.gitlab.com/ee/administration/package_information/supported_os.html),
|
||||
sowohl für Intel/AMD als auch für ARM-Prozessoren. Das offizielle Docker-Image ist
|
||||
jedoch nur für die arm64-Architektur verfügbar.
|
||||
|
||||
GitLab hat unter allen getesteten Plattformen den höchsten Ressourcenverbrauch: im
|
||||
Leerlauf bewegt sich die CPU-Last auf meinem Testsystem zwischen 3 und 30 Prozent. Der
|
||||
Arbeitsspeicherverbrauch beträgt ganze 6GB.
|
||||
|
||||
Aufwändige Git-Operationen können Lastspitzen über 100% für eine Dauer von bis zu 5
|
||||
Sekunden pro Anfrage verursachen.
|
||||
|
||||
GitLab erwähnt in ihrer Dokumentation, dass man die Konfiguration anpassen kann, um den
|
||||
Ressourcenverbrauch etwas zu senken. Nachdem ich diese Zeilen zur Konfigurationsdatei
|
||||
hinzugefügt habe, sank der Speicherbedarf auf 2.8GB und die CPU-Auslastung auf 1-12%.
|
||||
|
||||
```
|
||||
# Reduce the number of running workers to the minimum in order to reduce memory usage
|
||||
puma['worker_processes'] = 2
|
||||
sidekiq['max_concurrency'] = 9
|
||||
# Turn off monitoring to reduce idle cpu and disk usage
|
||||
prometheus_monitoring['enable'] = false
|
||||
```
|
||||
|
||||
Für eine Installation auf Single Board-Computern und kleinen V-Servern ist der
|
||||
Speicherverbrauch jedoch weiterhin zu hoch. GitLab gibt als Mindestanforderung 4
|
||||
CPU-Kerne und 4GB RAM an.
|
||||
|
||||
## Bedienung
|
||||
|
||||
Gitlab's Weboberfläche ist eine Single-Page-Anwendung, d.h. die gesamte Weboberfläche
|
||||
wird clientseitig mittels JavaScript dargestellt. Dies erlaubt eine äußerst flüssige
|
||||
Navigation durch die Webseite, da die Seite nicht bei jedem Navigationsschritt neu
|
||||
geladen wird. Der Nachteil dieser Lösung: Javascript ist für die Darstellung der
|
||||
Webseite zwingend erforderlich.
|
||||
|
||||
GitLab bietet die Möglichkeit, den Code eines Repositories zu durchsuchen. Die
|
||||
Verwendung einer externen Elasticsearch-Instanz für die Suche und die Möglichkeit, die
|
||||
gesamte Gitlab-Instanz zu durchsuchen, ist allerdings den kostenpflichtigen Versionen
|
||||
vorbehalten.
|
||||
|
||||
GitLab unterstützt in der Standardkonfiguration die meisten Dateiformate unter den
|
||||
getesteten Plattformen. Auf der Weboberfläche können Bilder, CSV-Tabellen, PDF-Dokumente
|
||||
und stl-Modelle betrachtet werden, alternative Markupsprachen wie Restructured Text
|
||||
werden ebenfalls unterstützt. Es gibt sogar die Möglichkeit, GeoJSON-Dateien (Listen von
|
||||
GPS-Standorten) auf einer OpenStreetMap-Karte darzustellen.
|
||||
|
||||
Eine Besonderheit der Gitea-Weboberfläche stellt die Web-IDE dar. GitLab verfügt über
|
||||
eine modifizierte Version von Visual Studio Code, mit der man direkt im Browser an
|
||||
seinen Projekten arbeiten kann.
|
||||
|
||||
|
||||
|
||||
## Import bestehender Projekte
|
||||
|
||||
GitLab erlaubt den Projektimport von GitHub, Bitbucket, FogBugz, Gitea sowie von anderen
|
||||
GitLab-Instanzen.
|
||||
|
||||
Die Importfunktion ist standardmäßig deaktiviert und muss erst in der _Admin Area_
|
||||
aktiviert werden (_Settings_ \> _General_ \> _Visibility and access controls_ \> _Import
|
||||
sources_).
|
||||
|
||||
Für den Import von GitHub-Projekten muss man sich mit einem Access Token anmelden und
|
||||
bekommt anschließend eine Übersicht aller Repositories angezeigt. Hier kann man
|
||||
auswählen, welche Repositories übertragen werden sollten. Der Import umfasst auch
|
||||
Issues, Pull Requests und Releases.
|
||||
|
||||
|
||||
|
||||
Als einzige Plattform im Test bietet GitLab die Möglichkeit, ein Repository mit
|
||||
sämtlichen gespeicherten Daten als zip-Datei zu exportieren. Dies erlaubt nicht nur den
|
||||
Import auf anderen Instanzen sondern bietet dem Nutzer auch eine Backup-Option.
|
||||
|
||||
## Zusatzfeatures
|
||||
|
||||
GitLab hat von allen getesteten Plattformen die meisten Features. Einige Features sind
|
||||
jedoch der proprietären Premium/Ultimate Edition vorbehalten, die ich nicht getestet
|
||||
habe.
|
||||
|
||||
Die Projektmanagement-Features von GitLab sind die besten im Test. GitLab erlaubt das
|
||||
Erstellen von Issues mit Labels, Verantwortlichen, Fälligkeitsterminen und geleisteter
|
||||
Arbeitszeit. Zudem können Issues zu Meilensteinen hinzugefügt werden.
|
||||
|
||||
Issue Boards erlauben einen schnellen Überblick über den alle gerade bearbeiteten
|
||||
Issues. Es lassen sich Spalten erstellen, die Issues mit einem bestimmten Tag auflisten.
|
||||
Erstellt man also z.B. zwei Tags: "Implementierung" und "Review" und legt in seinem
|
||||
Board zwei Spalten hierfür an, erhält man eine Übersicht über den Fortschritt aller
|
||||
Issues. Issues lassen sich zwischen Spalten verschieben, wodurch sich auch die Tags des
|
||||
Issues ändern.
|
||||
|
||||
|
||||
|
||||
Ein interessantes Feature ist die Möglichkeit, zu einem Issue mehrere Tasks
|
||||
hinzuzufügen. Tasks sind Sub-Issues, die ihre eigene Beschreibung und Diskussion haben,
|
||||
aber unter einem Issue zusammengefasst sind. Auf diese Weise lassen sich große Features
|
||||
in kleinere Arbeitsschritte aufteilen, die von verschiedenen Teammitgliedern erledigt
|
||||
werden können.
|
||||
|
||||
|
||||
|
||||
Viele fortgeschrittene Projektmanagement-Features sind allerdings der Enterprise Edition
|
||||
vorbehalten. Hierzu gehört z.B. das Anlegen von Boards mit Filtern (z.B. für einen
|
||||
bestimmten Meilenstein) oder Aufwandsschätzungen.
|
||||
|
||||
Um Projekte zu dokumentieren bietet GitLab ein auf Git und Markdown basierendes Wiki.
|
||||
Zudem gibt es mit "Snippets" einen Pastebin, der ebenfalls Git zur Speicherung der
|
||||
Codeschnipsel verwendet.
|
||||
|
||||
Es gibt auch die Möglichkeit, mit GitLab statische Webseiten zu hosten. Die Seiten
|
||||
können mit GitLab CI gebaut und unter einer persönlichen Subdomain veröffentlicht
|
||||
werden.
|
||||
|
||||
GitLab bietet auch eine Paketregistry für Bibliotheken verschiedener Programmiersprachen
|
||||
(z.B. Maven, npm, Python) an. Die Unterstützung für einige Programmiersprachen wie Ruby
|
||||
ist allerdings noch experimentell. \*.deb-Pakete sowie Docker-Images können ebenfalls
|
||||
mit GitLab gehostet werden.
|
||||
|
||||
Zur einfachen Bedienung mit der Kommandozeile bietet GitLab das Tool `glab` an. Damit
|
||||
lassen sich beispielsweise Issues und Pull Requests erstellen und bearbeiten, Snippets
|
||||
hochladen und CI-Build starten. Es gibt auch ein offizielles VS-Code-Plugin, das
|
||||
Pull-Requests, Issues und CI-Builds in den Texteditor integriert.
|
||||
|
||||
## Continous Integration
|
||||
|
||||
Gitlab verfügt über ein eingebautes CI-System, um Software automatisiert zu testen und
|
||||
zu veröffentlichen. Das System kann Builds in Docker-Containern, auf einem
|
||||
Kubernetes-Cluster, in einer VirtualBox-Maschine oder ohne Virtualisierung ausführen.
|
||||
Hierfür verwendet Gitlab ein verteiltes System aus Runnern. Die Runner kommunizieren
|
||||
über das Internet mit der Gitlab-Instanz und können so neue Buildaufträge
|
||||
entgegennehmen.
|
||||
|
||||
Um einen Runner einzurichten, muss man zuerst die erforderliche Konfigurationsdatei
|
||||
erstellen. Hierfür startet man den Runner mit dem Befehl `register`:
|
||||
|
||||
```
|
||||
docker run --rm -it -v $(pwd)/runner-config:/etc/gitlab-runner gitlab/gitlab-runner register
|
||||
```
|
||||
|
||||
Daraufhin fragt der Runner nach der URL der Gitlab-Instanz und einem
|
||||
Registrierungstoken. Den Token kann man sich entweder in den Repository-Einstellungen
|
||||
oder in der Admin-Oberfläche generieren lassen (je nachdem, ob man den Runner nur zu
|
||||
einem Projekt oder der gesamten Instanz hinzufügen möchte). Anschließend muss man
|
||||
festlegen, wie der Runner die Builds ausführen sollte. In meinem Test habe ich den
|
||||
`docker`-Executor gewählt.
|
||||
|
||||
Wenn die Konfiguration abgeschlossen ist, kann man den Runner mit diesem Befehl starten
|
||||
|
||||
```
|
||||
docker run --rm -it -v $(pwd)/runner-config:/etc/gitlab-runner gitlab/gitlab-runner
|
||||
```
|
||||
|
||||
|
||||
|
||||
Anschließend kann man für sein Repository einen Build definieren. Hierfür muss man eine
|
||||
Datei mit dem Namen `.gitlab-ci.yml` im Wurzelverzeichnes des Repositories erstellen, in
|
||||
der die einzelnen Schritte des Builds beschrieben werden. GitLab stellt ein Repository
|
||||
mit Beispielen für verschiedene Programmiersprachen und Frameworks zur Verfügung, um den
|
||||
Einstieg zu erleichtern.
|
||||
|
||||
```yml
|
||||
image: "rust:latest"
|
||||
|
||||
test:cargo:
|
||||
script:
|
||||
- rustc --version && cargo --version # Print version info for debugging
|
||||
- rustup component add rustfmt clippy
|
||||
- cargo fmt --all --check
|
||||
- cargo clippy --all --features=rss -- -D warnings
|
||||
- cargo test --features=rss --workspace
|
||||
```
|
||||
|
||||
## Öffentliche Instanzen
|
||||
|
||||
Gitlab betreibt selbst eine öffentliche Instanz der proprietären Ultimate-Version unter
|
||||
[gitlab.com](https://gitlab.com/explore/).
|
||||
|
||||
Daneben gibt es eine Vielzahl von communitybetriebenen GitLab-Instanzen, die die freie
|
||||
Community Edition verwenden. Viele große Open-Source-Projekte und Organisationen hosten
|
||||
eine eigene GitLab-Instanz, wie zum Beispiel [Debian](https://salsa.debian.org),
|
||||
[Framasoft](https://framagit.org/public/projects/) oder [KDE](https://invent.kde.org).
|
||||
|
||||
## Fazit
|
||||
|
||||
GitLab ist zu Recht seit mehr als zehn Jahren die führende quelloffene
|
||||
GitHub-Alternative. Mittlerweile bietet GitLab mehr Features als die Konkurrenz von
|
||||
Microsoft.
|
||||
|
||||
Trotz seiner komplexen Architektur lässt sich GitLab relativ einfach und schnell
|
||||
installieren, da das Omnibus-Paket die einzelnen Dienste automatisch konfiguriert.
|
||||
|
||||
Insbesondere Unternehmen und große Organisationen werden die professionellen Features
|
||||
und den kommerziellen Support zu schätzen wissen.
|
||||
|
||||
Darüber hinaus bietet Gitlab selbst in der Open-Source-Version die besten
|
||||
Projektmanagement-Features im Test. Wer also keine separate Projektmanagement-Anwendung
|
||||
einsetzen möchte, ist mit Gitlab ebenfalls gut beraten.
|
||||
|
||||
Wer seine Plattform allerdings auf einem kleinen Single Board Computer oder V-Server
|
||||
betreiben möchte, sollte sich dagegen nach einer leichtgewichtigeren Alternative
|
||||
umsehen.
|
||||
|
||||
## Quellen
|
||||
|
||||
- Dokumentation <https://docs.gitlab.com/>
|
||||
- Repository <https://gitlab.com/gitlab-org/gitlab-foss/>
|
||||
- Architekturübersicht
|
||||
<https://docs.gitlab.com/ee/development/architecture.html#gitlab-architecture-overview>
|
||||
- Liste von öffentlichen GitLab-Instanzen
|
||||
<https://wiki.p2pfoundation.net/List_of_Community-Hosted_GitLab_Instances>
|
||||
331
src/studienarbeit/3_gitea.md
Normal file
331
src/studienarbeit/3_gitea.md
Normal file
|
|
@ -0,0 +1,331 @@
|
|||
# Gitea
|
||||
|
||||
Das Gitea-Projekt begann 2016 als Fork der Git-Hosting-Plattform Gogs. Lunny Xiao, einer
|
||||
der Beitragenden von Gogs, war damit unzufrieden, dass der Gründer des Projekts, Joe
|
||||
Chen, das Projekt alleine betreuen und keine weiteren Maintainer ernennen wollte.
|
||||
|
||||
2022 gründete Lunny Xiao die Firma Gitea Limited. Die Firma bietet Unternehmen Hosting-
|
||||
und Supportdienstleistungen für Gitea an. Da einige Mitglieder der Community einem
|
||||
kommerziell geleiteten Open-Source-Projekt misstrauen, entstand ein neuer Fork names
|
||||
Forgejo. Forgejo steht unter der Leitung von Codeberg, einem Berliner Verein, der seit
|
||||
2018 eine öffentliche Gitea-Instanz betreibt. Abgesehen von Design- und Namensänderungen
|
||||
unterscheidet sich Forgejo von Gitea momentan kaum.
|
||||
|
||||
Gitea ist in Go geschrieben und besteht aus einer einzigen ausführbaren Datei.
|
||||
Standardmäßig verwendet Gitea eine interne SQLite-Datenbank, alternativ werden auch
|
||||
externe Datenbanken (MySQL, MariaDB, Postgres, MS SQL) unterstützt.
|
||||
|
||||
Die Weboberfläche wied serverseitig mit Templates gerendert. Einige Websitekomponenten
|
||||
wie z.B. Drop-Down-Menüs erfordern JavaScript.
|
||||
|
||||
Getestet wurde die Version 1.20.0-rc2.
|
||||
|
||||
## Installation
|
||||
|
||||
Gitea stellt kompilierte Binaries für alle gängigen Betriebssysteme unter
|
||||
<https://dl.gitea.com/gitea/> zur Verfügung. Von dort aus lässt sich die Anwendung
|
||||
einfach herunterladen und starten.
|
||||
|
||||
Alternativ gibt es auch [offizielle](https://pkgs.org/download/gitea) und
|
||||
[inoffizielle](https://gitea.com/gitea/awesome-gitea/src/branch/main/README.md#user-content-packages)
|
||||
Pakete für die meisten Linux-Distributionen.
|
||||
|
||||
Darüber hinaus stellt Gitea auch ein Docker-Image (`gitea/gitea`) zur Verfügung.
|
||||
|
||||
Die Einrichtung ist extrem simpel. Beim ersten Start wird diese Konfigurationsseite
|
||||
angezeigt, auf der man die grundlegenden Einstellungen (z.B. Datenbank-URL,
|
||||
Admin-Passwort) vornehmen kann. Nach der Bestätigung ist Gitea in wenigen Sekunden
|
||||
bereit zur Verwendung.
|
||||
|
||||
|
||||
|
||||
Dieser Konfigurationsassistent wird jedoch nur beim ersten Start angezeigt. Alle
|
||||
weiteren Konfigurationsänderungen müssen durch die
|
||||
`app.ini`-[Konfigurationsdatei](https://docs.gitea.com/1.20/administration/config-cheat-sheet)
|
||||
erfolgen. Gitea verfügt zwar über eine Admin-Oberfläche, diese dient allerdings
|
||||
hauptsächlich der Nutzerverwaltung und erlaubt keine Konfigurationsänderungen.
|
||||
|
||||
## Systemanforderungen
|
||||
|
||||
Gitea ist auf jedem Betriebssystem und jeder CPU-Architektur lauffähig, die von der
|
||||
Programmiersprache Go unterstützt wird. Binaries für MacOS (amd64/aarch64), FreeBSD
|
||||
(amd64), Windows (i386/amd64) und Linux (i386/amd64/arm5/arm6/aarch64) werden offiziell
|
||||
zum Download angeboten. Das offizielle Docker-Image ist für die amd64- und
|
||||
aarch64-Architektur verfügbar.
|
||||
|
||||
Im Leerlauf benötigt der Server ca. 150MB Arbeitsspeicher und verursacht unter 0.1%
|
||||
CPU-Auslastung. Bei aufwändigen Git-Operationen steigt die CPU-Auslastung auf bis zu 30%
|
||||
für maximal 2 Sekunden.
|
||||
|
||||
Damit ist Gitea die mit Abstand leichtgewichtigste Plattform in Test und eignet sich
|
||||
perfekt für den Einsatz auf schwächerer Hardware.
|
||||
|
||||
## Bedienung
|
||||
|
||||
Die Weboberfläche von Gitea wird serverseitig mit Hilfe von Templates gerendert
|
||||
(klassische Multi-Page-Anwendung). Dies hat den Vorteil, dass die Seite auch ohne
|
||||
JavaScript dargestellt werden kann (wenn auch mit eingeschränkter Bedienbarkeit).
|
||||
|
||||
Obwohl bei jedem Navigationsschritt durch ein Repository die gesamte Seite neu geladen
|
||||
wird, läuft die Navigation durch Ordner sehr flüssig.
|
||||
|
||||
Optisch und funktional ist die Benutzerschnittstelle stark an GitHub angelehnt. Wer also
|
||||
vorher GitHub verwendet hat, findet sich auf Gitea schnell zurecht
|
||||
|
||||
Der Code in Gitea-Repositories kann durchsucht werden, allerdings ist diese Funktion
|
||||
standardmäßig deaktiviert. Um sie zu aktivieren, müssen diese Zeilen zur
|
||||
Konfigurationsdatei hinzugefügt werden:
|
||||
|
||||
```
|
||||
[indexer]
|
||||
REPO_INDEXER_ENABLED=true
|
||||
```
|
||||
|
||||
Standardmäßig verwendet Gitea die Bibliothek [Bleve](https://blevesearch.com/) für die
|
||||
Suche, es kann jedoch auch eine externe Elasticsearch-Instanz verwendet werden.
|
||||
|
||||
|
||||
|
||||
Gitea kann standardmäßig Bilder, CSV-Dateien, PDFs und Markdown-Dateien auf der
|
||||
Weboberfläche darstellen. Andere Markupsprachen wie ReStructured Text werden
|
||||
standardmäßig nicht unterstützt. Allerdings bietet Gitea als einzige getestete Plattform
|
||||
die Möglichkeit, zusätzliche Renderer in der Konfigurationsdatei zu definieren.
|
||||
Beispielsweise kann Gitea Pandoc verwenden, um RST, LaTEX oder Word-Dokumente in HTML zu
|
||||
konvertieren und anzuzigen. Es ist auch möglich, mit etwas Bastelei einen Viewer für STL
|
||||
oder Excel-Dateien zu installieren.
|
||||
|
||||
## Import bestehender Projekte
|
||||
|
||||
Gitea bietet die Möglichkeit, Projekte von GitHub, Gitlab, Gogs, OneDev, GitBucket und
|
||||
Codebase zu importieren. Neben den Repositories können auch Issues, Pull-Requests und
|
||||
Releases importiert werden.
|
||||
|
||||
Der Versuch, zwei meiner GitHub-Projekte mit Issues und Pull-Requests zu übertragen,
|
||||
scheiterte jedoch mit einer Fehlermeldung.
|
||||
|
||||
## Zusatzfeatures
|
||||
|
||||
Gitea bietet grundlegende Features zum Projektmanagement. Issues können erstellt, mit
|
||||
Labels versehen und bestimmten Entwicklern zugewiesen werden. Es können
|
||||
Fälligkeitstermine für Issues festgelegt und die Arbeitszeit hinterlegt werden.
|
||||
|
||||
Dazu kommt die Möglichkeit, Issues zu Meilensteinen hinzuzufügen und somit
|
||||
beispielsweise den Arbeitsfortschritt für eine neue Version zu verfolgen.
|
||||
|
||||
Darüber hinaus können in Gitea Kanbanboards erstellt werden. Allerdings sind diese
|
||||
Boards nicht in das restliche Issue-System integriert und deswegen umständlich zu
|
||||
nutzen. Issues müssen beispielsweise manuell den Boards hinzugefügt werden. Während
|
||||
GitLab Labels verwendet, um die Issues den Spalten zuzuordnen ist in Gitea außerhalb des
|
||||
Boards nicht ersichtlich, welchen Status ein Issue hat. Ein Issue, das in die
|
||||
Done-Spalte verschoben wird, wird nicht automatisch geschlossen. Umgekehrt führt das
|
||||
Schließen eines Issues nicht zu einer Platzierung in der Done-Spalte.
|
||||
|
||||
Dokumentation für Gitea-Repositories kann in einem simplen, auf Markdown basierenden
|
||||
Wiki veröffentlicht werden.
|
||||
|
||||
Das Hosting statischer Webseiten unterstützt Gitea nicht, weswegen das Team von Codeberg
|
||||
hierfür eine [eigene Lösung](https://codeberg.org/Codeberg/pages-server) entwickelt hat.
|
||||
|
||||
Gitea bietet eine integrierte Registry für Pakete aller gängigen Programiersprachen
|
||||
(z.B. Python, npm, Rust). Wer eine Softwarebibliothek entwickelt, kann diese auf seiner
|
||||
Gitea-Instanz veröffentlichen, sodass andere Entwickler sie nutzen können. Zudem
|
||||
unterstützt die Gitea-Registry Linux-Pakete (.deb und .rpm) sowie Docker-Images.
|
||||
|
||||
Gitea unterstützt als einzige getestete Plattform agit. Dies ist ein alternativer
|
||||
Git-Workflow, der von Alibaba entwickelt wurde. Agit erlaubt es Entwicklern, Pull
|
||||
Requests zu erstellen ohne zuvor einen Fork des Projekts anzulegen. Hierbei wird die
|
||||
Änderung mit diesem Befehl in einen versteckten Branch des Reposiories gepusht, worauf
|
||||
Gitea automatisch eine PR erstellt.
|
||||
|
||||
Dieser Befehl erfordert im Gegensatz zum normalen push keine Schreibrechte im
|
||||
entsprechenden Repository.
|
||||
|
||||
```
|
||||
git push origin HEAD:refs/for/main -o topic="feat/user-search" -o title="Add user search"
|
||||
```
|
||||
|
||||
Es existiert auch ein Git-Plugin für agit namens
|
||||
[`git-repo`](https://git-repo.info/en/2020/03/agit-flow-and-git-repo/), damit man nicht
|
||||
jedes Mal diesen langen Befehl eintippen muss, sondern den Beschreibungstext direkt in
|
||||
die Kommandozeile tippen kann.
|
||||
|
||||
Gitea lässt sich auch mit dem Tool [`tea`](https://gitea.com/gitea/tea) auf der
|
||||
Kommandozeile bedienen. Auf diese Weise lassen sich Issues erstellen und lesen oder Pull
|
||||
Requests erstellen und abrufen.
|
||||
|
||||
Gitea bietet dem Administrator vollen Zugriff auf seinen Webserver und das
|
||||
Templatesystem. Dadurch kann man Templates und Stylesheets durch eigens angepasste
|
||||
Versionen ersetzen und die Weboberfläche nach seinen Bedürfnissen anpassen. Dies ist
|
||||
insbesondere für große Organisationen und Firmen interessant, die ihre
|
||||
Git-Hosting-Plattform nach ihrem Corporate Design gestalten möchten.
|
||||
|
||||
Ein Beispiel für eine stark angepasste Gitea-Oberfläche ist die Instanz des
|
||||
[Blender-Projekts](https://projects.blender.org/), die sich nahtlos in die restliche
|
||||
Projektseite einfügt.
|
||||
|
||||
## Continous Integration
|
||||
|
||||
### Woodpecker
|
||||
|
||||
Gitea verfügte lange nicht über einen eingebauten CI-Server. Allerdings gibt es eine
|
||||
Schnittstelle, um externe CI-Systeme anzubinden.
|
||||
|
||||
Ich habe einige CI-Systeme getestet, die mit Gitea kompatibel sind.
|
||||
[Woodpecker](https://woodpecker-ci.org/) ist meiner Meinung nach eines der besten
|
||||
Systeme. Bei Woodpecker handelt es sich um einen Fork des Drone CI-Projekts nach deren
|
||||
Wechsel von der Apache License zu einer nichtkommerziellen Lizent.
|
||||
|
||||
Woodpecker erlaubt den Login mit seinem Gitea-Account und zeigt dem Entwickler auf der
|
||||
Startseite eine Liste aller Repositories an. Von dort aus lässt sich die CI für
|
||||
bestimmte Repositories aktivieren. Daraufhin konfiguriert Woodpecker die Webhooks des
|
||||
Repositories, sodass die Builds automatisch bei Aktualisierungen gestartet werden.
|
||||
|
||||
Woodpecker verwendet sogenannte Agents, die mittels GRPC mit dem zentralen Server
|
||||
kommunizieren und Buildaufträge empfangen. Die Agents verwenden Docker, um die Builds in
|
||||
Containern auszuführen.
|
||||
|
||||
|
||||
|
||||
Die Builds werden in einer yml-Datei mit dem Namen `.woodpecker.yml` im
|
||||
Wurzelverzeichnes des Repositories definiert. Jeder Buildschritt wird in einem eigenen
|
||||
Docker-Container ausgeführt.
|
||||
|
||||
```yaml
|
||||
pipeline:
|
||||
test:
|
||||
image: rust:latest
|
||||
commands:
|
||||
- rustup component add rustfmt clippy
|
||||
- cargo fmt --all --check
|
||||
- cargo clippy --all --features=rss -- -D warnings
|
||||
- cargo test --features=rss --workspace
|
||||
```
|
||||
|
||||
Die Installation von Woodpecker ist etwas komplizierter, da Woodpecker sowohl einen
|
||||
HTTP-Server als auch einen GRPC-Server bereitstellt. Möchte man Agents auf anderen
|
||||
Servern betreiben, sollte auch der GRPC-Server mit TLS gesichert sein. Hierfür kann man
|
||||
einen Reverse Proxy (z.B Traefik) verwenden. Allerdings beinhaltet die offizielle
|
||||
Dokumentation keine Anleitung hierfür.
|
||||
|
||||
[Hier](./assets/woodpecker/docker-compose.yml) ist die Docker-Compose-Datei, die ich für
|
||||
meine Setup (mit Traefik) verwendet habe. Vor der Verwendung müssen noch die folgenden
|
||||
Konfigurationsvariablen bearbeitet werden:
|
||||
|
||||
- `WOODPECKER_HOST` URL der Woodpecker-Instanz
|
||||
- `WOODPECKER_GITEA_URL` URL der Gitea-Instanz
|
||||
- `WOODPECKER_GITEA_CLIENT` / `WOODPECKER_GITEA_SECRET` OAuth-Zugangsdaten (in Gitea das
|
||||
Einstellungsmenü aufrufen und unter _Create a new OAuth2 Application_ einen neuen
|
||||
Client erstellen. Redirect URI: `<WOODPECKER_URL>/authorize`)
|
||||
- `WOODPECKER_AGENT_SECRET` ist das Passwort für alle mit der Instanz verbundenen
|
||||
Agents. Hierfür sollte man sich einfach einen langen Zufallsstring erzeugen,
|
||||
beispielsweise mit `openssl rand -hex 32`.
|
||||
|
||||
### Gitea Actions
|
||||
|
||||
Mit dem vorletzten Release 1.19 bekam Gitea jedoch ein eigenes CI-System: Gitea Actions.
|
||||
Hierbei wurde nicht nur der Name an die Konkurrenz von Microsoft angelehnt. Das System
|
||||
basiert auf [act](https://github.com/nektos/act), einer freien Implementation von GitHub
|
||||
Actions. Ursprünglich wurde act zum lokalen Testen von GitHub Actions entwickelt. Gitea
|
||||
hat die Anwendung stattdessen als Basis für ihr CI-System verwendet.
|
||||
|
||||
Standardmäßig sind Gitea Actions in den Einstellungen deaktiviert. Um sie verwenden zu
|
||||
können, muss man diese Zeilen zur Konfigurationsdatei hinzufügen:
|
||||
|
||||
```
|
||||
[actions]
|
||||
ENABLED=true
|
||||
```
|
||||
|
||||
Anschließend muss man wie bei Gitlab und Woodpecker einen Runner einrichten, der die
|
||||
Builds mittels Docker ausführt. Der Runner kann als Binary von der
|
||||
[Gitea-Download-Seite](https://dl.gitea.com/act_runner/) heruntergeladen werden. Es ist
|
||||
auch möglich, den Runner in einem Docker-Container zu betreiben.
|
||||
|
||||
Nachdem man den Runner heruntergeladen hat, muss man ihn konfigurieren. Dafür führt man
|
||||
den Befehl `act-runner register` auf. Anschließend muss man die Adresse der Instanz und
|
||||
einen Registrierungstoken, den man in der Admin-Oberfläche unter _Actions / Runners_
|
||||
erzeugen kann.
|
||||
|
||||
Anschließend muss man noch die Actions im gewünschten Repository aktivieren, in dem man
|
||||
in den Einstellungen den Haken bei _Enable Repository Actions_ setzt.
|
||||
|
||||
Die Builds werden als yaml-Dateien im Verzeichnis `.gitea/workflows` definiert. Obwohl
|
||||
Gitea die gleiche Syntax wie Github Actions verwendet, sind die Workflows nicht 1:1
|
||||
kompatibel. Beispielsweise lädt Gitea vordefinierte Actions wie `actions/checkout` nicht
|
||||
von [github.com/actions](https://github.com/actions) sondern von
|
||||
[gitea.com/actions](https://gitea.com/actions) herunter, sodass einige Actions nicht
|
||||
verfügbar sind.
|
||||
|
||||
Außerdem führt GitHub seine Builds in einer virtuellen Maschine mit einer Vielzahl an
|
||||
vorinstallierten Programmiersprachen und Entwicklertools aus. Da das Image dieser
|
||||
Maschine sehr groß ist, benutzt Gitea stattdessen standardmäßig den
|
||||
Debian+NodeJS-Container `node:16-bullseye`. Das Image enthält neben Node.js auch Python,
|
||||
gcc, make und curl. Wer andere Programmiersprachen benutzt, muss jedoch Anwendungen
|
||||
nachinstallieren (wie beispielsweise Rust im unteren Beispiel). Es ist jedoch möglich,
|
||||
andere Docker-Images zu verwenden.
|
||||
|
||||
```yaml
|
||||
name: Test
|
||||
on: [push]
|
||||
|
||||
jobs:
|
||||
Test:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Check out repository code
|
||||
uses: actions/checkout@v3
|
||||
- name: Setup Rust
|
||||
run: |
|
||||
curl https://sh.rustup.rs -sSf | sh -s -- -y
|
||||
source "$HOME/.cargo/env"
|
||||
- name: Test
|
||||
run: |
|
||||
cargo clippy
|
||||
cargo test
|
||||
```
|
||||
|
||||
|
||||
|
||||
Ein wichtiges Feature, das Gitea Actions momentan noch fehlt ist die Möglichkeit,
|
||||
Workflows manuell zu starten. Da Gitea Actions noch relativ neu ist, gehe ich jedoch
|
||||
davon aus, dass dieses Feature in Zukunft implementiert wird.
|
||||
|
||||
## Öffentliche Instanzen
|
||||
|
||||
Die von den Maintainern des Projekts betriebene Instanz unter
|
||||
[gitea.com](https://gitea.com/explore/repos) verfügt über 5600 Repositories.
|
||||
|
||||
Eine noch größere Instanz betreibt der Berliner Verein Codeberg e.V. Auf
|
||||
[codeberg.org](https://codeberg.org) werden 30900 öffentliche Repositories gehostet.
|
||||
Zusätzlich zu ihrer Gitea-Instanz bietet Codeberg auch einen Webhosting-Dienst unter
|
||||
[\*.codeberg.page](https://codeberg.page) an. Codeberg betreibt auch einen
|
||||
Woodpecker-CI-Server, für dessen Verwendung die Nutzer allerdings manuell freigeschaltet
|
||||
werden müssen.
|
||||
|
||||
Da Gitea sehr einfach und günstig zu hosten ist, wird es von einigen Open
|
||||
Source-Projekten auch als sekundäre Plattform zusätzlich zu GitHub verwendet.
|
||||
Beispielsweise betreibt das Team hinter dem alternativen YouTube-Frontend Invidious eine
|
||||
[Gitea-Instanz](https://gitea.invidious.io/iv-org), um vor eventuellen Takedowns des
|
||||
Repositories auf GitHub sicher zu sein
|
||||
|
||||
## Fazit
|
||||
|
||||
Während GitLab meiner Meinung nach die beste Lösung für große Organisationen und
|
||||
Unternehmen darstellt, ist Gitea das perfekte System für einzelne Entwickler, kleine
|
||||
Teams und Hobbybastler. Durch seinen sparsamen Ressourcenverbrauch ist Gitea auf fast
|
||||
jeder Hardware lauffähig und die Einrichtung funktioniert einfach und schnell.
|
||||
|
||||
Darüber hinaus lässt sich Gitea mit eigenen Themes und Templates individuell anpassen
|
||||
und zu seiner persönlichen Website machen.
|
||||
|
||||
Die Projektmanagement-Features von Gitea sind allerdings eher rudimentär. Wer
|
||||
Kanbanboards benötigt, sollte Gitlab oder OneDev in Betracht ziehen oder hierfür eine
|
||||
externe Software verwenden.
|
||||
|
||||
## Quellen
|
||||
|
||||
- Projektseite <https://gitea.com>
|
||||
- Repository <https://github.com/go-gitea/gitea/>
|
||||
- Start von Codeberg (damals TeaHub)
|
||||
<https://www.heise.de/news/Neue-Entwickler-Plattform-TeaHub-will-Github-beerben-4078811.html>,
|
||||
<https://blog.codeberg.org/codebergorg-launched.html>
|
||||
292
src/studienarbeit/4_sourcehut.md
Normal file
292
src/studienarbeit/4_sourcehut.md
Normal file
|
|
@ -0,0 +1,292 @@
|
|||
# Sourcehut
|
||||
|
||||
Eine Git-Hosting-Plattform ohne Pull-Requests, einer spartanischen Weboberfläche und
|
||||
einem mächtigen Buildsystem - so lässt sich Sourcehut am besten zusammenfassen.
|
||||
|
||||
|
||||
|
||||
SourceHut begann im
|
||||
[Oktober 2016](https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/40dcb38349af3f67845857c4ac9003911a653624)
|
||||
als Hobbyprojekt von Drew DeVault. Drew wollte eine alternative zu den etablierten
|
||||
Git-Hosting-Diensten entwickeln, die den klassischen E-Mail-basierten Git-Workflow
|
||||
unterstützt anstatt das Funktionsprinzip von GitHub zu kopieren.
|
||||
|
||||
[2018](https://drewdevault.com/2018/11/15/sr.ht-general-availability.html) war die
|
||||
Alpha-Version der Software öffentlich unter <https://sr.ht> verfügbar.
|
||||
|
||||
Die Plattform besteht aus einzelnen Komponenten für die verschiedenen Features:
|
||||
|
||||
- meta.sr.ht (Login und Benutzerverwaltung)
|
||||
- hub.sr.ht (Projektverwaltung)
|
||||
- git.sr.ht / hg.sr.ht (Git/Mercurial Hosting)
|
||||
- todo.sr.ht (Issues)
|
||||
- lists.sr.ht (Mailinglisten)
|
||||
- man.sr.ht (Wiki)
|
||||
- paste.sr.ht (Pastebin)
|
||||
- builds.sr.ht (Continuous Integration)
|
||||
- pages.sr.ht (Statisches Webhosting)
|
||||
|
||||
Jede dieser Komponentent besteht wiederum aus 2-3 Diensten: dem in Python/Flask
|
||||
implementierten Webfrontend, einem in Go geschriebenen API-Server und eventuell noch
|
||||
zusätzliche Dienste wie eine Task Queue.
|
||||
|
||||
Jede Komponente legt ihre Daten in einer eigenen PostgreSQL-Datenbank ab. Zusätzlich
|
||||
wird noch eine gemeinsame Redis-Instanz als Cache und Event Queue verwendet.
|
||||
|
||||
Hier ist eine Übersicht über die einzelnen Dienste:
|
||||
|
||||
|
||||
|
||||
## Installation
|
||||
|
||||
Da Sourcehut aus mehreren Services für die einzelnen Features besteht, ist die
|
||||
Einrichtung mit deutlich mehr Aufwand verbunden. Die Anleitung zur Installation findet
|
||||
sich auf der [Dokumentationsseite](https://man.sr.ht/installation.md) des Projekts.
|
||||
Allerdings ist diese Anleitung nicht vollständig und ich musste an einigen Stellen im
|
||||
Quellcode der Software nachschlagen, wie bestimmte Features zu konfigurieren sind.
|
||||
|
||||
Erschwerend kommt hinzu, dass Sourcehut an vielen Stellen keine aussagekräftigen
|
||||
Fehlermeldungen liefert. Beispielsweise hatte ich das Problem, dass builds.sr.ht keine
|
||||
VMs starten konnte, da diese standardmäßig mit 4GB RAM konfiguriert sind - zu viel für
|
||||
meine Test-VM. Der einzige Fehler, der in diesem Fall auf der Webseite angezeigt wird,
|
||||
ist der, dass das Build-System innerhalb einer bestimmten Zeit keine Verbindung zur VM
|
||||
aufbauen konnte. Der OOM-Fehler beim Start wurde weder geloggt noch an den Nutzer
|
||||
weitergegeben.
|
||||
|
||||
Auf der Dokumentationsseite wird erwähnt, dass sich das Projekt noch im Alpha-Stadium
|
||||
befindet, es ist also zu hoffen, dass die Dokumentation in Zukunft verbessert wird.
|
||||
|
||||
Ich habe sämtliche Schritte, die zur Installation meiner Testinstanz erforderlich waren,
|
||||
im [Anhang](sourcehut_setup.md) aufgelistet.
|
||||
|
||||
## Systemanforderungen
|
||||
|
||||
Sourcehut ist auf jedem System lauffähig, das Python 3.10 und Go unterstützt. Allerdings
|
||||
sind die Pakete momentan nur für die amd64-Architektur verfügbar. Wer Sourcehut also auf
|
||||
einem Raspberry Pi oder ARM-Server installieren will, muss die Pakete selbst
|
||||
kompilieren.
|
||||
|
||||
Die CPU-Auslastung im Leerlauf ist gering (ca. 1%). Bei aufwändigen Git-Operationen
|
||||
sieht die Sache jedoch anders aus. Wenn man sich z.B. die Änderungshistorie der Makefile
|
||||
des Linux-Kernels anzeigen lässt, läuft git.sr.ht 30 Sekunden lang mit 100%
|
||||
CPU-Auslastung, bis Nginx die Anfrage wegen Zeitüberschreitung abbricht. Dieses Problem
|
||||
lässt sich auch auf der offiziellen Instanz reproduzieren
|
||||
([Link zum Testen](https://git.sr.ht/~gregkh/linux-stable/log/master/item/Makefile)).
|
||||
|
||||
Zum Vergleich: Die Ausführung des Befehls `git --no-pager log Makefile | head -n 1000`
|
||||
benötigte auf meinem Testsystem nur 100ms.
|
||||
|
||||
Beim Arbeitsspeicherverbrauch macht sich die Microservice-Architektur negativ bemerkbar:
|
||||
jeder Python-Dienst reserviert 90-100MB, die in Go geschriebenen API-Server kommen mit
|
||||
20-30MB RAM aus. Da die gesamte Sourcehut-Installation aus 14 Python- und 8 Go-Services
|
||||
besteht, summiert sich der Arbeitsspeicherbedarf auf ca. 1,5GB.
|
||||
|
||||
## Bedienung
|
||||
|
||||
Sourcehut's Weboberfläche ist spartanisch designt und kommt fast ohne JavaScript aus.
|
||||
Dadurch ist die Webseite ohne Probleme in alten Geräten und Browsern benutzbar.
|
||||
|
||||
Die Repository-Ansicht ist klar an GitWeb angelehnt und zeigt die Dateien ähnlich wie
|
||||
der `ls -l`-Befehl zusammen mit Größe und Berechtigungen an.
|
||||
|
||||
Genau wie GitWeb (und ls) platziert Sourcehut Ordner nicht vor Dateien, was das
|
||||
Auffinden bestimmter Ordner unter vielen Dateien erschwert.
|
||||
|
||||
Eine Suchfunktion gibt es nicht, dadurch ist es schwierig, auf der Webseite durch große
|
||||
Projekte zu navigieren.
|
||||
|
||||
Hinzu kommt, dass die Webseite nur Code und Markdown-Dokumente darstellen kann. Bilder,
|
||||
PDF-Dokumente oder andere Markupsprachen wie RST werden nicht unterstützt.
|
||||
|
||||
|
||||
|
||||
Die einzelnen Komponenten von Sourcehut sind eigenständige Webanwendungen. Dies hat den
|
||||
Vorteil, dass man nur einen Teil von Sourcehut installieren kann, wenn man
|
||||
beispielsweise den Build-Service oder die Mailinglisten nicht benötigt. Allerdings macht
|
||||
diese Aufteilung die Bedienung an vielen Stellen hakelig. Es gibt zwar eine zentrale
|
||||
Projektverwaltung (hub.sr.ht), die Repositories, Issue-Tracker und Mailinglisten zu
|
||||
bestimmten Projekten zuordnet. Allerdings ist diese Verlinkung eine Einbahnstraße: von
|
||||
der Projekseite auf dem Hub kann man alle zugehörigen Repositories, Issue-Tracker und
|
||||
Mailinglisten aufrufen, befindet man sich aber bspw. in einem Repository, kann man das
|
||||
zugehörige Projekt nicht ohne weiteres ermitteln.
|
||||
|
||||
 Projektansicht im SourceHut Hub
|
||||
|
||||
Sourcehut unterscheidet sich von GitHub und anderen Code-Hosting-Plattformen vor allem
|
||||
dadurch, dass es zur Kollaboration zwischen Entwicklern keine Pull-Requests verwendet.
|
||||
Stattdessen basiert das System auf den "klassischen" Git-Workflow, also dem Austausch
|
||||
von Patches via E-Mail. Projekteigentümer können Mailinglisten einrichten und darüber
|
||||
Patches empfangen.
|
||||
|
||||
Dies hat den Vorteil, dass außenstehende Entwickler sich nicht auf der Plattform
|
||||
registrieren müssen und ausschließlich via E-Mail mit den Maintainern des Projekts
|
||||
kommunizieren können.
|
||||
|
||||
Sourcehut bietet Entwicklern auch die Möglichkeit, über die Weboberfläche Patches zu
|
||||
erstellen und zu versenden. Dazu muss man das Repository zuerst auf der Plattform
|
||||
klonen, die eigenen Commits hochladen und diese anschießend in der Weboberfläche
|
||||
auswählen.
|
||||
|
||||
|
||||
|
||||
Auch wenn dieser Workflow sicherlich Vorteile mit sich bringt, muss man feststellen,
|
||||
dass dies für die meisten Entwickler ungewohnt und umständlich ist. Entwickler, die
|
||||
bisher nur mit GitHub und ähnlichen Plattformen gearbeitet haben, werden beim Versuch,
|
||||
zu einem Projekt beizutragen, eventuell auf Hindernisse stoßen.
|
||||
|
||||
Es gibt auch ein CLI-Tool namens [hut](https://git.sr.ht/~emersion/hut), um die
|
||||
verschiedenen Sourcehut-Dienste mit der Kommandozeile zu bedienen. Das Tool erlaubt das
|
||||
Erstellen von Issues, Hochladen von Releases, Starten von Builds, Veröffentlichen von
|
||||
Webseiten, Hinzufügen von SSH-Keys und einiges mehr.
|
||||
|
||||
## Import bestehender Projekte
|
||||
|
||||
Die Sourcehut-Weboberfläche erlaubt auf lediglich den Import von öffentlichen
|
||||
Git-Repositories per clone. Es gibt keine Möglichkeit zum Import von Issues und
|
||||
Pull-Requests werden wie oben erwähnt nicht unterstützt.
|
||||
|
||||
## Zusatzfeatures
|
||||
|
||||
Wie bereits beschrieben besteht Sourcehut aus einer Vielzahl von Diensten, den
|
||||
Entwicklern neben Git-Hosting und Issue Tracking diverse Zusatzfeatures bieten.
|
||||
|
||||
man.sr.ht ist ein auf Git basierendes Wiki, das in Markdown geschriebene
|
||||
Dokumentationstexte darstellen kann. Allerdings bietet es kaum Features: der einzige
|
||||
Unterschied zum Betrachten von Markdown-Dateien in git.sr.ht ist das
|
||||
Seiteninhaltsverzeichnis, das man.sr.ht oben anfügt. Es gibt kein Inhaltsverzeichnis
|
||||
über die gesamte Dokumentation, genauso wenig wie eine Suchfunktion.
|
||||
|
||||
paste.sr.ht ist ein Pastebin zum Speichern und Veröffentlichen von kleineren Texten,
|
||||
Skripten und Codeausschnitten. Man kann Pastes öffentlich oder privat speichern und es
|
||||
gibt auch die Möglichkeit, Textdateien mit dem `hut`-CLI-Tool hochzuladen.
|
||||
|
||||
pages.sr.ht ist ein Webhosting-Dienst, der es einem erlaubt, statische Webseiten unter
|
||||
einer persönlichen Subdomain zu veröffentlichen. Hierfür muss man sämtliche Dateien als
|
||||
`tar.gz`-Archiv komprimieren und anschließend mit dem `hut`-Tool hochladen.
|
||||
|
||||
Das Issue-System von Sourcehut (todo.sr.ht) ist jedoch sehr rudimentär. Es gibt außer
|
||||
Labels und der Möglichkeit, verantwortliche Personen zuzuweisen keine Zusatzfunktionen,
|
||||
die das Projektmanagement erleichtern. Für größere Projekte ist daher die Verwendung
|
||||
einer zusätzlichen Projektmanagement-Software wie Redmine nötig.
|
||||
|
||||
## Continous Integration
|
||||
|
||||
builds.sr.ht ist ein sehr leistungsfähiges und einfach zu verwendender CI-System.
|
||||
|
||||
Builds können über die Weboberfläche, eine API oder durch Git-Pushes und auf der
|
||||
Mailigliste eingegangene Patches initiiert werden. Zum Ausführen der Builds werden
|
||||
virtuelle Maschinen (mit QEMU/KVM) gestartet, wodurch die Build-Umgebung vom Server
|
||||
isoliert ist.
|
||||
|
||||
QEMU erlaubt es auch, andere CPU-Architekturen zu emulieren und so beispielsweise
|
||||
Embedded Linux-Anwendungen zu testen.
|
||||
|
||||
|
||||
|
||||
Sourcehut Builds werden durch
|
||||
[yaml-Manifests](https://man.sr.ht/builds.sr.ht/manifest.md) beschrieben. Die Syntax ist
|
||||
sehr simpel gehalten. Manifests bestehen aus dem Namen des VM-Images, den benötigten
|
||||
Paketen und Repositories und einem oder mehreren Shell-Skripten.
|
||||
|
||||
```yaml
|
||||
image: alpine/latest
|
||||
packages:
|
||||
- cargo
|
||||
sources:
|
||||
- https://code.thetadev.de/ThetaDev/short-uuid.git
|
||||
tasks:
|
||||
- test: |
|
||||
cd short-uuid
|
||||
cargo test
|
||||
```
|
||||
|
||||
Es gibt auch die Möglichkeit, für den Build benötige Secrets wie API-Keys und
|
||||
SSH-Schlüssel zu hinterlegen. Die Secrets werden auf der Build-VM in Dateien abgelegt,
|
||||
von wo aus sie in Buildskripten verwendet werden können (z.B.
|
||||
`cargo publish --token "$(<~/.cargo-token)"`). Zudem gibt es die Möglichkeit, SSH- und
|
||||
GPG-Schlüssel automatisch zu importieren.
|
||||
|
||||
Ein besonderes Feature von builds.sr.ht ist die Möglichkeit, fehlgeschlagene Builds zu
|
||||
analysieren. Schlägt ein Build fehl, läuft die entsprechende VM noch 10 Minuten weiter.
|
||||
In dieser Zeit kann man sich per SSH mit dem Build-Server verbinden und kann Befehle in
|
||||
der entsprechenden Build-VM ausführen. Auf diese Weise kann man Logdateien inspizieren
|
||||
oder den Build mit Konfigurationsänderungen neu starten, ohne jedes Mal das
|
||||
Buildmanifest zu ändern und neu zu übermitteln.
|
||||
|
||||
|
||||
|
||||
Allerdings bietet Sourcehut Builds nicht die Möglichkeit, zu spezifizieren, wann ein
|
||||
Build ausgeführt werden soll. Builds werden immer dann gestartet, wenn ein Branch in
|
||||
einem Repository aktualisiert wird, in dem sich eine `.builds.yml`-Datei befindet.
|
||||
Eingehende Patches in der Mailingliste können ebenfalls einen Build startet.
|
||||
|
||||
Es gibt jedoch keine Möglichkeit, Builds nur dann zu starten, wenn ein bestimmter Branch
|
||||
oder bestimmte Dateien aktualisiert wurden. Dies kann beispielsweise in Monorepos
|
||||
(Repositories mit mehreren Projekten) zu unnötig lange dauernden Builds führen.
|
||||
|
||||
## Öffentliche Instanzen
|
||||
|
||||
Die öffentliche Sourcehut-Instanz, die von Drew DeVault und seiner Firma betrieben wird,
|
||||
befindet sich unter <https://sr.ht>.
|
||||
|
||||
sr.ht ist der einige mir bekannte Git-Hosting-Anbieter, der ein kostenpflichtiges
|
||||
Abonnement für das Erstellen eigener Projekte erfordert. Solange sich Sourcehut im
|
||||
Alpha-Stadium befindet, ist das Abo allerdings optional (außer für die Nutzung des
|
||||
Build-Service). Das Abonnement kostet 20€ im Jahr, man kann auch auf freiwilliger Basis
|
||||
bis zum 100€ bezahlen, um das Projekt zu unterstützen.
|
||||
|
||||
Die kostenpflichtigen Mitgliedschaften erlauben Sourcehut, finanziell unabhängig zu sein
|
||||
und nicht den Entscheidungen von Investoren unterworfen zu sein. Sourcehut
|
||||
veröffentlicht seine jährlichen Einnahmen und Ausgaben auf ihrem Blog und gibt an, seit
|
||||
2019 Profit zu erwirtschaften.
|
||||
|
||||
Bekannte Projekte, die auf sr.ht gehostet werden sind das alternative Instagram-Frontend
|
||||
[Bibliogram](https://sr.ht/~cadence/bibliogram/),
|
||||
[microblog.pub](https://sr.ht/~tsileo/microblog.pub/), eine persönliche
|
||||
Microblogging-Anwendung mit ActivityPub-Unterstützung und natürlich
|
||||
[Sourcehut](https://sr.ht/~sircmpwn/sourcehut/) selbst. Insgesamt hostet sr.ht ca. 7100
|
||||
Projekte.
|
||||
|
||||
Es gibt auch Open-Source-Projekte, die ihren Code auf anderen Plattformen hosten und nur
|
||||
das Build-System von Sourcehut nutzen. Beispielsweise benutzt die Linux-Distribution
|
||||
postmarketOS [Sourcehut Builds](https://build.postmarketos.org/) zum Bau ihrer Pakete.
|
||||
|
||||
Wichtig ist noch zu erwähnen, dass die offizielle Sourcehut-Instanz keine Projekte
|
||||
erlaubt, die mit
|
||||
[Blockchain oder Kryptowährungen](https://sourcehut.org/blog/2022-10-31-tos-update-cryptocurrency/)
|
||||
zu tun haben. Sourcehut begründet dies damit, dass Kryptowährungen häufig für Betrug und
|
||||
andere Verbrechen eingesetzt werden und große Mengen an Ressourcen verschwenden.
|
||||
|
||||
Abgesehen von der offiziellen Instanz gibt es sehr wenige weiterem öffentlichen
|
||||
Sourcehut-Instanzen, was wohl auch dem komplizierten Einrichtungsprozess geschuldet ist.
|
||||
|
||||
Es existiert eine Instanz unter [gnu.org](https://sourcehut.gnu.org), die sich
|
||||
allerdings im Entwicklermodus befindet und über keine öffentlichen Projekte verfügt. Die
|
||||
größte alternative Sourcehut-Instanz, die ich gefunden habe, ist
|
||||
<https://code.netlandish.com/>. Die Instanz wird von einer Webentwicklungsfirma
|
||||
betrieben, beherbergt 9 öffentliche Projekte und erlaubt keine Registrierung von
|
||||
Außenstehenden.
|
||||
|
||||
## Fazit
|
||||
|
||||
Das Highlight von sr.ht ist meiner Meinung nach der CI-Dienst. Während die meisten
|
||||
anderen CI-Dienste an Repositories gekoppelt sind, erlaubt es Sourcehut, einfach ein
|
||||
Build-Manifest mit dem CLI-Tool oder dem Formular auf der Website abzuschicken und
|
||||
ausführen zu lassen. Die Möglichkeit fehlgeschlagene Builds zu analysieren ist ebenfalls
|
||||
einzigartig.
|
||||
|
||||
Allerdings ist die Einrichtung von Sourcehut sehr aufwändig und einige grundlegende
|
||||
Features wie eine Suchfunktion fehlen weswegen ich das System in seinem momentanen
|
||||
Zustand nicht empfehlen kann.
|
||||
|
||||
Hinzu kommt, dass Sourcehut trotz seiner spartanischen Weboberfläche und seinem
|
||||
reduziertem Funktionsumfang das System mit dem zweithöchsten Ressourcenverbrauch im Test
|
||||
war.
|
||||
|
||||
Da sich Sourcehut wie gesagt noch im Alpha-Stadium befindet, lohnt es sich jedoch das
|
||||
Projekt weiter zu verfolgen.
|
||||
|
||||
## Quellen
|
||||
|
||||
- Projektseite <https://sr.ht/~sircmpwn/sourcehut/>
|
||||
- Sourcehut Blog <https://sourcehut.org/blog/>
|
||||
232
src/studienarbeit/5_onedev.md
Normal file
232
src/studienarbeit/5_onedev.md
Normal file
|
|
@ -0,0 +1,232 @@
|
|||
# OneDev
|
||||
|
||||
Abschließen möchte ich meinen Test mit einer weitgehend unbekannten Plattform, die erst
|
||||
2019 als Hobbyprojekt von zwei Entwicklern veröffentlicht wurde, sich aber in Sachen
|
||||
Funktionalität nicht vor den anderen Plattformen verstecken muss: OneDev.
|
||||
|
||||
|
||||
|
||||
OneDev ist in Java geschrieben und verwendet das Webframework Apache Wicket. Das Projekt
|
||||
wird hauptächlich von Robin Shen und Steve Luo entwickelt, insgesamt gibt es ca. 30
|
||||
Beitragende. Das Projekt ist unter der MIT-Lizenz veröffentlicht.
|
||||
|
||||
Der
|
||||
[erste Commit](https://code.onedev.io/onedev/server/~commits/6be8e3f97c97e44cf6b5a9b8360c299cc55388f6)
|
||||
erfolgte im April 2012, die erste in Git getaggte Version (2.0.0) wurde 2019
|
||||
veröffentlicht. Rechnet man mit dem Datum des ersten Release, ist OneDev die jüngste der
|
||||
vier Plattformen, die ich getestet habe.
|
||||
|
||||
OneDev besteht aus einer einzigen Java-Anwendung und erfordert bei Verwendung der
|
||||
eingebetteten HSQL-Datenbank keine zusätzlichen Dienste zum Betrieb. Es werden auch
|
||||
externe Datenbanken (MySQL, MariaDB, Postgres, MS SQL, Oracle) unterstützt.
|
||||
|
||||
Getestet wurde die Version 8.5.2.
|
||||
|
||||
## Installation
|
||||
|
||||
Die OneDev-Entwickler stellen Container-Images für OneDev zur Verfügung
|
||||
(`docker.io/1dev/server`), mit denen sich OneDev einfach mittels Docker installieren
|
||||
lässt. Alternativ gibt es auch die Möglichkeit, die Java-Anwendung direkt auf seinem
|
||||
System zu installieren oder OneDev in einem Kubernetes-Cluster zu betreiben.
|
||||
|
||||
Für den Installationsprozess gibt es eine Schritt-für-Schritt-Anleitung auf der
|
||||
Dokumentationsseite des Projekts. Allerdings bin ich hiervon abgewichen, da in der
|
||||
Installationsanleitung empfohlen wird, den Docker-Socket (`/var/run/docker.sock`) im
|
||||
OneDev-Container als Volume einzubinden.
|
||||
|
||||
Dies ist nur dann erforderlich, wenn der eingebaute _Server Docker Executor_ anstelle
|
||||
eines externen Agents für CI-Jobs verwendet wird.
|
||||
|
||||
Da Container mit Docker-Zugriff effektiv über Root-Rechte auf dem Hostsystem verfügen,
|
||||
ist dies jedoch mit einem Sicherheitsrisiko verbunden. Deswegen empfehle ich, den
|
||||
eingebauten Agent nicht zu nutzen und stattdessen den seperaten Agent-Container
|
||||
(`docker.io/1dev/agent`) zu verwenden. Der CI-Agent sollte bei einem Produktionssetup
|
||||
auf einem anderen Server bzw. einer anderen VM laufen, auf der sich keine wertvollen
|
||||
oder sensiblen Daten befinden - insbesondere wenn nicht vertrauenswürdige Nutzer Zugriff
|
||||
auf das CI-System haben.
|
||||
|
||||
[Hier](./assets/onedev/docker-compose.yml) ist die Docker-Compose-Datei, die ich für
|
||||
meine Testinstallation verwendet habe.
|
||||
|
||||
Nach dem Start des Servers kann man auf der Weboberfläche den ersten Benutzeraccount
|
||||
anlegen und die URL des Servers konfigurieren.
|
||||
|
||||
Anschließend muss noch das CI-System eingerichtet werden. Hierzu öffnet man den
|
||||
Menüpunkt _Administration_ \> _Agents_, klickt auf _Tokens_ und generiert sich einen
|
||||
neuen Agent Token. Dieser Token muss dem Agent als Umgebungsvariable übergeben werden
|
||||
(also z.B. in die Docker-Compose-Datei eintragen). Nach dem Start des Agents muss dieser
|
||||
in der Tabelle sichtbar sein.
|
||||
|
||||
|
||||
|
||||
Danach öffnet man den Menüpunkt _Job Executors_ und erstellt einen _Remote Docker
|
||||
Executor_. Damit ist die Einrichtung des CI-Systems abgeschlossen und man kann den
|
||||
ersten Build starten (siehe im Abschnitt
|
||||
[Continuous Integration](#continous-integration)).
|
||||
|
||||
Standardmäßig erlaubt OneDev nur angemeldeten Benutzern den Zugriff auf die Instanz. Um
|
||||
seine Projekte öffentlich verfügbar zu machen, muss noch die Option _Security Settings_
|
||||
\> _Enable Anonymous Access_ aktiviert werden.
|
||||
|
||||
## Systemanforderungen
|
||||
|
||||
OneDev ist auf jedem System mit Java-Unterstützung lauffähig. Das offizielle
|
||||
Docker-Image wird für die 64bit Interl/AMD und ARM-Architektur angeboten.
|
||||
|
||||
Der Server benötigte auf meinem System ca. 1.2GB Arbeitsspeicher, der CI-Agent ca.
|
||||
180MB. Die CPU-Auslastung im Leerlauf beträgt auf meinem System (AMD Ryzen 5700G) ca.
|
||||
1%, mit gelegentlichen Spitzen auf 5-10%.
|
||||
|
||||
Aufwändige Git-Operationen (History/Blame in großen Repositories) können Lastspitzen von
|
||||
bis zu 100% mit einer Dauer von max. 2 Sekunden verursachen. Bei Nutzung der
|
||||
Suchfunktion habe ich bis zu 50% Auslastung gemessen.
|
||||
|
||||
## Bedienung
|
||||
|
||||
OneDev verfügt über eine modern gestaltete Weboberfläche, die mit dem Webframework
|
||||
Apache Wicket realisiert wurde. Das Framework lädt beim Navigieren nur die Teile der
|
||||
Website vom Server, die sich durch den entsprechenden Navigationsschritt geändert haben
|
||||
(also z.B. die Dateiliste).
|
||||
|
||||
Dadurch geht das Navigieren durch die Repositories sehr flüssig vonstatten, ohne dass
|
||||
die gesamte Seite neu geladen werden muss.
|
||||
|
||||
Ein Alleinstellungsmerkmal von OneDev ist die Suchfunktion. OneDev verwendet nicht nur
|
||||
eine Textsuchmaschine, sondern analysiert den Code im Repository und bietet so die
|
||||
Möglichkeit, nach Klassen und Funktionen zu suchen. Die Suchergebnisse werden während
|
||||
dem Tippen angezeigt. Auf diese Weise kann man schnell durch komplexe Softwareprojekte
|
||||
navigieren.
|
||||
|
||||
|
||||
|
||||
Die Suche kann auch über ein Kontextmenü in der Code-Ansicht aufgrufen werden. Auf diese
|
||||
Weise kann man nach Definitionen oder Verwendungen von Funktionen suchen. Es gibt auch
|
||||
eine Übersicht aller Klassen und Funktionen einer Datei auf der rechten Seite.
|
||||
|
||||
Die Code-Analyse ist für die Sprachen Java, JavaScript, C, C++, CSharp, Go, PHP, Python,
|
||||
CSS, SCSS, LESS und R verfügbar. Rust wird leider nicht unterstützt.
|
||||
|
||||
|
||||
|
||||
OneDev kann auf der Weboberfläche Code, Markdown-Dokumente und Bilder darstellen. Es
|
||||
gibt keine Unterstützung für alternative Markupsprachen wie RST.
|
||||
|
||||
## Import bestehender Projekte
|
||||
|
||||
OneDev bietet einen Import-Assistenten mit Unterstützung für GitHub, Gitlab, BitBucket,
|
||||
und Gitea. Neben dem Git-Repository werden auch Metadaten und Issues übertragen.
|
||||
|
||||
Der Importer erlaubt es auch, nach einer Authentifizierung per API-Key sämtliche
|
||||
Projekte eines Nutzers oder einer Organisation zu übertragen, was beim Umstieg viel Zeit
|
||||
sparen kann.
|
||||
|
||||
Es gibt jedoch nicht die Möglichkeit, Projekte aus anderen OneDev-Instanzen zu
|
||||
übertragen.
|
||||
|
||||
## Zusatzfeatures
|
||||
|
||||
OneDev verfügt über umfangreiche Tools zum Projektmanagement. Es gibt die Möglichkeit,
|
||||
Issues zu Meilensteinen zuzuordnen (z.B. _Sprint 14_ oder _Version 2.0_). Zudem verfügt
|
||||
OneDev über Issue Boards, um Issues je nach Status in mehreren Spalten anzuzeigen.
|
||||
|
||||
|
||||
|
||||
Issues können bestimmten Entwicklern zugewiesen werden und es gibt die Möglichkeit,
|
||||
Abhängigkeiten zwischen Issues zu definieren (z.B. Issue A muss vor Issue B erledigt
|
||||
werden). Was allerdings fehlt ist die Möglichkeit, einem Issue mehrere Labels
|
||||
zuzuordnen.
|
||||
|
||||
OneDev bietet auch die Möglichkeit, statische Webseiten zu hosten. Hierfür ist im
|
||||
Gegensatz zu Gitlab Pages keine separate Domain nötig. Stattdessen wird die Webseite im
|
||||
Unterverzeichnis `~site` des Repositorys (z.B. `https://example.com/user/repo/~site`)
|
||||
veröffentlicht.
|
||||
|
||||
Als einzige getestete Plattform verfügt OneDev über ein Plugin-System. Auf diese Weise
|
||||
lassen sich neue Features implementieren, ohne die Software verändern zu müssen.
|
||||
Beispielsweise gibt es ein Plugin zum
|
||||
[Import von Issues](https://github.com/DevCharly/onedev-plugin-import-redmine/) aus der
|
||||
Projektmanagement-Anwendung Redmine.
|
||||
|
||||
Weitere Zusatzfeatures wie Paketmanagement bietet OneDev nicht. Darüber hinaus fehlt die
|
||||
Möglichkeit, Releases seiner Software hochzuladen und mit Git-Tags zu verknüpfen. Dieses
|
||||
Feature beherrschen ansonsten alle getesteten Plattformen.
|
||||
|
||||
## Continous Integration
|
||||
|
||||
OneDev bietet ein eingebautes CI-System um Projekte zu kompilieren und zu testen. Die
|
||||
Jobs können in Docker-Containern, Kubernetes-Pods oder bare metal ausgeführt werden.
|
||||
|
||||
Jobs werden in einer yml-Datei definiert, die als `.onedev-buildspec.yml` im
|
||||
Wurzelverzeichnis des Repositories abgelegt werden muss.
|
||||
|
||||
OneDev bietet jedoch auch eine Weboberfläche, um Builds zu erstellen und zu bearbeiten.
|
||||
Auf diese Weise muss man nicht zuerst die yaml-Syntax erlernen, um das CI-System zu
|
||||
nutzen. Über die Weboberfläche lassen sich bestimmte Aktionen (z.B. "Befehle ausführen",
|
||||
"Docker Image bauen", "Webseite veröffentlichen") auswählen und konfigurieren.
|
||||
|
||||
|
||||
|
||||
```yml
|
||||
version: 23
|
||||
jobs:
|
||||
- name: test
|
||||
steps:
|
||||
- !CheckoutStep
|
||||
name: checkout
|
||||
cloneCredential: !DefaultCredential {}
|
||||
withLfs: false
|
||||
withSubmodules: false
|
||||
condition: ALL_PREVIOUS_STEPS_WERE_SUCCESSFUL
|
||||
- !CommandStep
|
||||
name: build
|
||||
runInContainer: true
|
||||
image: rust:latest
|
||||
interpreter: !DefaultInterpreter
|
||||
commands:
|
||||
- rustup component add rustfmt clippy
|
||||
- cargo fmt --all --check
|
||||
- cargo clippy --all --features=rss -- -D warnings
|
||||
- cargo test --features=rss --workspace
|
||||
useTTY: false
|
||||
condition: ALL_PREVIOUS_STEPS_WERE_SUCCESSFUL
|
||||
triggers:
|
||||
- !BranchUpdateTrigger {}
|
||||
- !PullRequestUpdateTrigger {}
|
||||
retryCondition: never
|
||||
maxRetries: 3
|
||||
retryDelay: 30
|
||||
timeout: 3600
|
||||
```
|
||||
|
||||
Die Builds können durch Branch Updates oder neue Pull Requests ausgelöst werden. Es gibt
|
||||
auch die Möglichkeit, Builds zeitgesteuert oder manuell zu starten.
|
||||
|
||||
## Öffentliche Instanzen
|
||||
|
||||
Das OneDev-Team betreibt ihre eigene Instanz unter
|
||||
[code.onedev.io](https://code.onedev.io). Allerdings verbietet diese Instanz das
|
||||
erstellen eigener Projekte und dient nur der Entwicklung und Demonstration der
|
||||
Plattform.
|
||||
|
||||
Darüber hinaus habe ich außer einer kleinen privaten Instanz names
|
||||
["Winux Projects"](https://projects.winux.it/) keine öffentlichen Instanzen gefunden,
|
||||
was sicher auch daran liegt, dass das Projekt momentan noch relativ unbekannt ist.
|
||||
|
||||
## Fazit
|
||||
|
||||
Obwohl OneDev noch relativ jung und weitgehend unbekannt ist, kann es funktional
|
||||
durchaus mit den Konkurrenten mithalten. Insbesondere die intelligente Suchfunktion und
|
||||
das einfach zu bedienende CI-System haben mir im Test sehr gut gefallen.
|
||||
|
||||
Allerdings ist OneDev immer noch ein Hobbyprojekt von 2 Entwicklern und hat keine Firma
|
||||
oder größere Organisation hinter sich. Wer OneDev beispielsweise in einem Unternehmen
|
||||
einsetzen möchte, muss die Einrichtung und den Support selbst übernehmen, da es im
|
||||
Gegensatz zu GitLab und Gitea keine öffentlichen Instanzen oder SaaS-Angebote gibt.
|
||||
|
||||
Wer sich hieran nicht stört, erhält mit OneDev eine leichtgewichtige, einfach zu
|
||||
installierende und moderne Git-Hosting-Plattform.
|
||||
|
||||
## Quellen
|
||||
|
||||
- Projektseite <https://onedev.io/>
|
||||
- Repository <https://code.onedev.io/onedev/server>
|
||||
BIN
src/studienarbeit/assets/gitea/actions.png
Normal file
BIN
src/studienarbeit/assets/gitea/actions.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
BIN
src/studienarbeit/assets/gitea/homepage.png
Normal file
BIN
src/studienarbeit/assets/gitea/homepage.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 98 KiB |
BIN
src/studienarbeit/assets/gitea/search.png
Normal file
BIN
src/studienarbeit/assets/gitea/search.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
BIN
src/studienarbeit/assets/gitea/setup.png
Normal file
BIN
src/studienarbeit/assets/gitea/setup.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
BIN
src/studienarbeit/assets/gitea/woodpecker.png
Normal file
BIN
src/studienarbeit/assets/gitea/woodpecker.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
BIN
src/studienarbeit/assets/gitlab/architecture.png
Normal file
BIN
src/studienarbeit/assets/gitlab/architecture.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
21
src/studienarbeit/assets/gitlab/docker-compose.yml
Normal file
21
src/studienarbeit/assets/gitlab/docker-compose.yml
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
version: "3.6"
|
||||
services:
|
||||
web:
|
||||
image: "gitlab/gitlab-ce:latest"
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
GITLAB_OMNIBUS_CONFIG: |
|
||||
external_url 'http://localhost:8001'
|
||||
nginx['listen_https'] = false
|
||||
nginx['listen_port'] = 80
|
||||
nginx['redirect_http_to_https'] = false
|
||||
letsencrypt['enable'] = false
|
||||
GITLAB_ROOT_PASSWORD: secret1234
|
||||
ports:
|
||||
- "8001:80"
|
||||
- "2222:22"
|
||||
volumes:
|
||||
- "./config:/etc/gitlab"
|
||||
- "./logs:/var/log/gitlab"
|
||||
- "./data:/var/opt/gitlab"
|
||||
shm_size: "256m"
|
||||
BIN
src/studienarbeit/assets/gitlab/import.png
Normal file
BIN
src/studienarbeit/assets/gitlab/import.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
BIN
src/studienarbeit/assets/gitlab/issue.png
Normal file
BIN
src/studienarbeit/assets/gitlab/issue.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
BIN
src/studienarbeit/assets/gitlab/kanban.png
Normal file
BIN
src/studienarbeit/assets/gitlab/kanban.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
src/studienarbeit/assets/gitlab/runners.png
Normal file
BIN
src/studienarbeit/assets/gitlab/runners.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
BIN
src/studienarbeit/assets/gitlab/web_ide.png
Normal file
BIN
src/studienarbeit/assets/gitlab/web_ide.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 226 KiB |
BIN
src/studienarbeit/assets/onedev/add_agent.png
Normal file
BIN
src/studienarbeit/assets/onedev/add_agent.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
BIN
src/studienarbeit/assets/onedev/build.png
Normal file
BIN
src/studienarbeit/assets/onedev/build.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 82 KiB |
BIN
src/studienarbeit/assets/onedev/ci_editor.png
Normal file
BIN
src/studienarbeit/assets/onedev/ci_editor.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
src/studienarbeit/assets/onedev/code_navigation.png
Normal file
BIN
src/studienarbeit/assets/onedev/code_navigation.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 136 KiB |
19
src/studienarbeit/assets/onedev/docker-compose.yml
Normal file
19
src/studienarbeit/assets/onedev/docker-compose.yml
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
version: "3"
|
||||
services:
|
||||
onedev:
|
||||
image: 1dev/server:latest
|
||||
ports:
|
||||
- 6610:6610
|
||||
- 6611:6611
|
||||
volumes:
|
||||
- ./data:/opt/onedev
|
||||
agent:
|
||||
image: 1dev/agent:latest
|
||||
environment:
|
||||
- "serverUrl=http://onedev:6610"
|
||||
- "agentToken=3922e711-8a7f-4dd0-8b68-fd3ca891ffff"
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
- ./work:/agent/work
|
||||
depends_on:
|
||||
- onedev
|
||||
BIN
src/studienarbeit/assets/onedev/homepage.png
Normal file
BIN
src/studienarbeit/assets/onedev/homepage.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
BIN
src/studienarbeit/assets/onedev/kanban.png
Normal file
BIN
src/studienarbeit/assets/onedev/kanban.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
src/studienarbeit/assets/onedev/search.png
Normal file
BIN
src/studienarbeit/assets/onedev/search.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 77 KiB |
BIN
src/studienarbeit/assets/sourcehut/failed_build.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/failed_build.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
BIN
src/studienarbeit/assets/sourcehut/homepage.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/homepage.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 99 KiB |
BIN
src/studienarbeit/assets/sourcehut/hub.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/hub.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
BIN
src/studienarbeit/assets/sourcehut/oauth.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/oauth.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 99 KiB |
BIN
src/studienarbeit/assets/sourcehut/oauth_new_client.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/oauth_new_client.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
BIN
src/studienarbeit/assets/sourcehut/repo.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/repo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
BIN
src/studienarbeit/assets/sourcehut/send_patchset.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/send_patchset.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
109
src/studienarbeit/assets/sourcehut/sourcehut.dio
Normal file
109
src/studienarbeit/assets/sourcehut/sourcehut.dio
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
<mxfile host="65bd71144e">
|
||||
<diagram id="oiookRJMGbAoKEPYmeVH" name="Page-1">
|
||||
<mxGraphModel dx="741" dy="808" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" background="#ffffff" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0"/>
|
||||
<mxCell id="1" parent="0"/>
|
||||
<mxCell id="3" value="Frontend<br>:5000" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="80" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="4" value="API<br>:5100" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="120" y="80" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="5" value="meta.sr.ht<br>(Nutzerverwaltung)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="140" y="50" width="60" height="10" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="6" value="Webhooks<br>(Queue)" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="80" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="8" value="Frontend<br>:5014" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="360" y="80" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="9" value="API<br>:5114" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="440" y="80" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="10" value="hub.sr.ht<br>(Startseite)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="410" y="50" width="60" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="11" value="Frontend<br>:5001" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="200" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="12" value="API<br>:5101" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="120" y="200" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="13" value="git.sr.ht<br>(Nutzerverwaltung)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="140" y="170" width="60" height="10" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="14" value="Webhooks<br>(Queue)" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="200" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="15" value="Frontend<br>:5004" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="360" y="200" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="16" value="API<br>:5104" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="440" y="200" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="17" value="man.sr.ht<br>(Wiki)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="410" y="170" width="60" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="18" value="Frontend<br>:5002" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="320" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="19" value="API<br>:5102" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="120" y="320" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="20" value="builds.sr.ht<br>(CI)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="140" y="290" width="60" height="10" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="21" value="Worker" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="320" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="22" value="Worker" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="210" y="330" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="23" value="Frontend<br>:5011" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="360" y="320" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="24" value="API<br>:5111" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="440" y="320" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="25" value="paste.sr.ht<br>(Wiki)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="410" y="290" width="60" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="26" value="Frontend<br>:5006" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="360" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="27" value="API<br>:5106" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="440" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="28" value="lists.sr.ht<br>(Mailinglisten)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="478" y="410" width="60" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="29" value="Process<br>(Queue)" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="560" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="30" value="LMTP" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="520" y="440" width="40" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="31" value="Frontend<br>:5003" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="32" value="API<br>:5103" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="120" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="33" value="todo.sr.ht<br>(Issues)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontColor=#141414;" parent="1" vertex="1">
|
||||
<mxGeometry x="158" y="410" width="60" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="34" value="Webhooks<br>(Queue)" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="240" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="35" value="LMTP" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="440" width="40" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="36" value="Webhooks<br>(Queue)" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="640" y="440" width="80" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
BIN
src/studienarbeit/assets/sourcehut/sourcehut.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/sourcehut.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
1
src/studienarbeit/assets/sourcehut/sourcehut_arch.svg
Normal file
1
src/studienarbeit/assets/sourcehut/sourcehut_arch.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 34 KiB |
BIN
src/studienarbeit/assets/sourcehut/successful_build.png
Normal file
BIN
src/studienarbeit/assets/sourcehut/successful_build.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
523
src/studienarbeit/assets/sourcehut_setup/config.ini
Normal file
523
src/studienarbeit/assets/sourcehut_setup/config.ini
Normal file
|
|
@ -0,0 +1,523 @@
|
|||
[sr.ht]
|
||||
# The name of your network of sr.ht-based sites
|
||||
site-name=sourcehut
|
||||
#
|
||||
# The top-level info page for your site
|
||||
site-info=https://sourcehut.org
|
||||
#
|
||||
# {{ site-name }}, {{ site-blurb }}
|
||||
site-blurb=the hacker's forge
|
||||
#
|
||||
# If this != production, we add a banner to each page
|
||||
environment=production
|
||||
#
|
||||
# Contact information for the site owners
|
||||
owner-name=Drew DeVault
|
||||
owner-email=sir@cmpwn.com
|
||||
#
|
||||
# The source code for your fork of sr.ht
|
||||
source-url=https://git.sr.ht/~sircmpwn/srht
|
||||
#
|
||||
# Link to your instance's privacy policy. Uses the sr.ht privacy policy as the
|
||||
# default, which describes the information collected by the upstream SourceHut
|
||||
# code.
|
||||
privacy-policy=
|
||||
#
|
||||
# A key used for encrypting session cookies. Use `srht-keygen service` to
|
||||
# generate the service key. This must be shared between each node of the same
|
||||
# service (e.g. git1.sr.ht and git2.sr.ht), but different services may use
|
||||
# different keys. If you configure all of your services with the same
|
||||
# config.ini, you may use the same service-key for all of them.
|
||||
service-key=9654c9ec7bedab6321a7f29f8b1b607ba023ddb9e248a67e10c49122e59a335f
|
||||
#
|
||||
# A secret key to encrypt internal messages with. Use `srht-keygen network` to
|
||||
# generate this key. It must be consistent between all services and nodes.
|
||||
network-key=iZnfEOgNVuCw6uGPQx1LE6eKVd20GXnd9IgCD3wxKJA=
|
||||
#
|
||||
# The redis host URL. This is used for caching and temporary storage, and must
|
||||
# be shared between nodes (e.g. git1.sr.ht and git2.sr.ht), but need not be
|
||||
# shared between services. It may be shared between services, however, with no
|
||||
# ill effect, if this better suits your infrastructure.
|
||||
redis-host=redis://localhost:6379
|
||||
#
|
||||
# Optional email address for reporting security-related issues.
|
||||
security-address=
|
||||
#
|
||||
# The global domain of the site. If unset, the global domain will be determined
|
||||
# from the service URL: each service is assumed to be a sub-domain of the global
|
||||
# domain, i.e. of the form `meta.globaldomain.com`.
|
||||
global-domain=codeforge.int
|
||||
|
||||
[mail]
|
||||
# Outgoing SMTP settings
|
||||
smtp-host=
|
||||
smtp-port=
|
||||
smtp-from=user@example.org
|
||||
#
|
||||
# Default: starttls
|
||||
# Options: starttls, tls, insecure
|
||||
smtp-encryption=tls
|
||||
#
|
||||
# Default: plain
|
||||
# Options: plain, none
|
||||
smtp-auth=plain
|
||||
# user / password are required if smtp-auth is plain
|
||||
smtp-user=user@example.org
|
||||
smtp-password=pass
|
||||
|
||||
pgp-privkey=/etc/sr.ht/gpg/privkey.gpg
|
||||
pgp-pubkey=/etc/sr.ht/gpg/pubkey.gpg
|
||||
pgp-key-id=E77640E3C9BA474C9C0791547298D360EE7DB9B4
|
||||
|
||||
[webhooks]
|
||||
#
|
||||
# base64-encoded Ed25519 key for signing webhook payloads. This should be
|
||||
# consistent between all services.
|
||||
#
|
||||
# Use the `srht-keygen webhook` command to generate this key. Put the private
|
||||
# key here and distribute the public key to anyone who would want to verify
|
||||
# webhook payloads from your service.
|
||||
private-key=FMCFMBL9HX3OHkYFoDUetJzxNfHw0vwWgLFKACXdoCY=
|
||||
|
||||
[meta.sr.ht]
|
||||
#
|
||||
# URL meta.sr.ht is being served at (protocol://domain)
|
||||
origin=http://meta.codeforge.int
|
||||
# Address and port to bind the debug server to
|
||||
# debug-host=127.0.0.1
|
||||
# debug-port=5000
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://meta:1234@localhost/meta.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# The redis connection used for the webhooks worker
|
||||
webhooks=redis://localhost:6379/1
|
||||
#
|
||||
# If "yes", the user will be sent the stock sourcehut welcome emails after
|
||||
# signup (requires cron to be configured properly). These are specific to the
|
||||
# sr.ht instance so you probably want to patch these before enabling this.
|
||||
welcome-emails=no
|
||||
|
||||
#
|
||||
# Origin URL for the API
|
||||
# By default, the API port is 100 more than the web port
|
||||
api-origin=http://localhost:5100
|
||||
|
||||
[meta.sr.ht::api]
|
||||
#
|
||||
# Maximum complexity of GraphQL queries. The higher this number, the more work
|
||||
# that API clients can burden the API backend with. Complexity is equal to the
|
||||
# number of discrete fields which would be returned to the user. 200 is a good
|
||||
# default.
|
||||
max-complexity=200
|
||||
|
||||
#
|
||||
# The maximum time the API backend will spend processing a single API request.
|
||||
#
|
||||
# See https://golang.org/pkg/time/#ParseDuration
|
||||
max-duration=3s
|
||||
|
||||
#
|
||||
# Set of IP subnets which are permitted to utilize internal API
|
||||
# authentication. This should be limited to the subnets from which your
|
||||
# *.sr.ht services are running.
|
||||
#
|
||||
# Comma-separated, CIDR notation.
|
||||
internal-ipnet=127.0.0.0/8,::1/128,192.168.0.0/16,10.0.0.0/8
|
||||
|
||||
[meta.sr.ht::settings]
|
||||
#
|
||||
# If "no", public registration will not be permitted.
|
||||
registration=yes
|
||||
#
|
||||
# Where to redirect new users upon registration
|
||||
onboarding-redirect=http://codeforge.int
|
||||
|
||||
[meta.sr.ht::aliases]
|
||||
#
|
||||
# You can add aliases for the client IDs of commonly used OAuth clients here.
|
||||
#
|
||||
# Example:
|
||||
# git.sr.ht=12345
|
||||
|
||||
[meta.sr.ht::billing]
|
||||
#
|
||||
# "yes" to enable the billing system
|
||||
enabled=no
|
||||
#
|
||||
# Get your keys at https://dashboard.stripe.com/account/apikeys
|
||||
stripe-public-key=
|
||||
stripe-secret-key=
|
||||
|
||||
[meta.sr.ht::auth]
|
||||
#
|
||||
# What authentication method to use.
|
||||
# builtin: use sr.ht builtin authentication
|
||||
# unix-pam: use Unix PAM authentication
|
||||
auth-method=builtin
|
||||
|
||||
[hub.sr.ht]
|
||||
#
|
||||
# URL hub.sr.ht is being served at (protocol://domain)
|
||||
origin=http://codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
# debug-host=127.0.0.1
|
||||
# debug-port=5014
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://hub:1234@localhost/hub.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# hub.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=712f709b315e4441
|
||||
oauth-client-secret=a186072ee9900662841188857777f44f
|
||||
|
||||
[git.sr.ht]
|
||||
#
|
||||
# URL git.sr.ht is being served at (protocol://domain)
|
||||
origin=http://git.codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
#debug-host=0.0.0.0
|
||||
#debug-port=5001
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://git:1234@localhost/git.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# The redis connection used for the webhooks worker
|
||||
webhooks=redis://localhost:6379/1
|
||||
#
|
||||
# A post-update script which is installed in every git repo.
|
||||
post-update-script=/usr/bin/gitsrht-update-hook
|
||||
#
|
||||
# git.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=33e27e614a5a6c99
|
||||
oauth-client-secret=e128d76adb42d64290381facab1a9db1
|
||||
#
|
||||
# Path to git repositories on disk
|
||||
repos=/var/lib/git/
|
||||
#
|
||||
# Configure the S3 bucket and prefix for object storage. Leave empty to disable
|
||||
# object storage. Bucket is required to enable object storage; prefix is
|
||||
# optional.
|
||||
#s3-bucket=
|
||||
#s3-prefix=
|
||||
#
|
||||
# Required for preparing and sending patchsets from git.sr.ht
|
||||
outgoing-domain=
|
||||
|
||||
#
|
||||
# Origin URL for the API
|
||||
# Only needed if not run behind a reverse proxy, e.g. for local development.
|
||||
# By default, the API port is 100 more than the web port
|
||||
#api-origin=http://localhost:5101
|
||||
|
||||
[git.sr.ht::api]
|
||||
#
|
||||
# Maximum complexity of GraphQL queries. The higher this number, the more work
|
||||
# that API clients can burden the API backend with. Complexity is equal to the
|
||||
# number of discrete fields which would be returned to the user. 200 is a good
|
||||
# default.
|
||||
max-complexity=200
|
||||
|
||||
#
|
||||
# The maximum time the API backend will spend processing a single API request.
|
||||
#
|
||||
# See https://golang.org/pkg/time/#ParseDuration
|
||||
max-duration=3s
|
||||
|
||||
#
|
||||
# Set of IP subnets which are permitted to utilize internal API
|
||||
# authentication. This should be limited to the subnets from which your
|
||||
# *.sr.ht services are running.
|
||||
#
|
||||
# Comma-separated, CIDR notation.
|
||||
internal-ipnet=127.0.0.0/8,::1/128,192.168.0.0/16,10.0.0.0/8
|
||||
|
||||
[git.sr.ht::dispatch]
|
||||
#
|
||||
# The authorized keys hook uses this to dispatch to various handlers
|
||||
# The format is a program to exec into as the key, and the user to match as the
|
||||
# value. When someone tries to log in as this user, this program is executed
|
||||
# and is expected to omit an AuthorizedKeys file.
|
||||
#
|
||||
# Uncomment the relevant lines to enable the various sr.ht dispatchers.
|
||||
/usr/bin/gitsrht-keys=git:git
|
||||
/usr/bin/buildsrht-keys=builds:builds
|
||||
|
||||
[todo.sr.ht]
|
||||
#
|
||||
# URL todo.sr.ht is being served at (protocol://domain)
|
||||
origin=http://todo.codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
#debug-host=0.0.0.0
|
||||
#debug-port=5003
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://todo:1234@localhost/todo.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# todo.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=215b592aa1e401b6
|
||||
oauth-client-secret=05f0d7ba973c6e4f2e0b5c95f00510f4
|
||||
#
|
||||
# Outgoing email for notifications generated by users
|
||||
notify-from=user@example.org
|
||||
#
|
||||
# The redis connection used for the webhooks worker
|
||||
webhooks=redis://localhost:6379/1
|
||||
#
|
||||
# Origin URL for the API
|
||||
# Only needed if not run behind a reverse proxy, e.g. for local development.
|
||||
# By default, the API port is 100 more than the web port
|
||||
#api-origin=http://localhost:5103
|
||||
|
||||
[todo.sr.ht::mail]
|
||||
#
|
||||
# Path for the lmtp daemon's unix socket. Direct incoming mail to this socket.
|
||||
# Alternatively, specify IP:PORT and an SMTP server will be run instead.
|
||||
sock=/tmp/todo.sr.ht-lmtp.sock
|
||||
#
|
||||
# The lmtp daemon will make the unix socket group-read/write for users in this
|
||||
# group.
|
||||
sock-group=postfix
|
||||
#
|
||||
# Fill this in with the name of the domain to which emails should be sent.
|
||||
# Leave blank to disable email submission.
|
||||
posting-domain=
|
||||
|
||||
[lists.sr.ht]
|
||||
#
|
||||
# URL lists.sr.ht is being served at (protocol://domain)
|
||||
origin=http://lists.codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
#debug-host=0.0.0.0
|
||||
#debug-port=5006
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://lists:1234@localhost/lists.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# The redis connection used for the webhooks worker
|
||||
webhooks=redis://localhost:6379/1
|
||||
#
|
||||
# The redis connection used for the Celery worker (configure this on both the
|
||||
# master and workers)
|
||||
redis=redis://localhost:6379/0
|
||||
#
|
||||
# The domain that incoming email should be sent to. Forward mail sent here to
|
||||
# the LTMP socket.
|
||||
posting-domain=lists.codeforge.int
|
||||
#
|
||||
# lists.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=95b6e656251e01f9
|
||||
oauth-client-secret=c6a53f7ac6e242dcbae198b738ce9c9a
|
||||
#
|
||||
# Trusted upstream SMTP server generating Authentication-Results header fields
|
||||
msgauth-server=mail.sr.ht.local
|
||||
#
|
||||
# If "no", prevents non-admins from creating new lists
|
||||
allow-new-lists=yes
|
||||
#
|
||||
# Origin URL for the API
|
||||
# Only needed if not run behind a reverse proxy, e.g. for local development.
|
||||
# By default, the API port is 100 more than the web port
|
||||
#api-origin=http://localhost:5106
|
||||
|
||||
[lists.sr.ht::worker]
|
||||
# Protocol used by the daemon. Either lmtp or smtp. By default ltmp if using
|
||||
# unix socket and smtp if using tcp socket.
|
||||
protocol=lmtp
|
||||
#
|
||||
# Path for the lmtp daemon's unix socket. Direct incoming mail to this socket.
|
||||
# Alternatively, specify IP:PORT will run the server using tcp.
|
||||
sock=/tmp/lists.sr.ht-lmtp.sock
|
||||
#
|
||||
# The lmtp daemon will make the unix socket group-read/write for users in this
|
||||
# group.
|
||||
sock-group=postfix
|
||||
#
|
||||
# Comma-delimited list of Content-Types to reject. Messages with Content-Types
|
||||
# included in this list are rejected. Multipart messages are always supported,
|
||||
# and each part is checked against this list.
|
||||
#
|
||||
# Uses fnmatch for wildcard expansion.
|
||||
reject-mimetypes=
|
||||
#
|
||||
# Link to include in the rejection message where senders can get help
|
||||
# correcting their email.
|
||||
reject-url=https://man.sr.ht/lists.sr.ht/etiquette.md
|
||||
|
||||
[lists.sr.ht::api]
|
||||
#
|
||||
# Maximum complexity of GraphQL queries. The higher this number, the more work
|
||||
# that API clients can burden the API backend with. Complexity is equal to the
|
||||
# number of discrete fields which would be returned to the user. 200 is a good
|
||||
# default.
|
||||
max-complexity=200
|
||||
|
||||
#
|
||||
# The maximum time the API backend will spend processing a single API request.
|
||||
#
|
||||
# See https://golang.org/pkg/time/#ParseDuration
|
||||
max-duration=90s
|
||||
|
||||
#
|
||||
# Set of IP subnets which are permitted to utilize internal API
|
||||
# authentication. This should be limited to the subnets from which your
|
||||
# *.sr.ht services are running.
|
||||
#
|
||||
# Comma-separated, CIDR notation.
|
||||
internal-ipnet=127.0.0.0/8,::1/128,192.168.0.0/16,10.0.0.0/8
|
||||
|
||||
[lists.sr.ht::redirects]
|
||||
#
|
||||
# Redirects for migrating old mailing lists to new ones. This just sets up the
|
||||
# redirect for incoming emails.
|
||||
#
|
||||
# old-address=~example/new-name
|
||||
|
||||
[man.sr.ht]
|
||||
#
|
||||
# URL man.sr.ht is being served at (protocol://domain)
|
||||
origin=http://man.codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
#debug-host=0.0.0.0
|
||||
#debug-port=5004
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://man:1234@localhost/man.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# man.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=96319d48a50cdfe5
|
||||
oauth-client-secret=e405e716b052402c88035c6ab429e6d3
|
||||
|
||||
[builds.sr.ht]
|
||||
#
|
||||
# URL builds.sr.ht is being served at (protocol://domain)
|
||||
origin=http://builds.codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
#debug-host=0.0.0.0
|
||||
#debug-port=5002
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://builds:1234@localhost/builds.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# The redis connection used for the Celery worker (configure this on both the
|
||||
# master and workers)
|
||||
redis=redis://localhost:6379/0
|
||||
#
|
||||
# builds.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=ecfda530d17ae5c3
|
||||
oauth-client-secret=68176355b4de8865163748e0a1ec1551
|
||||
#
|
||||
# Script used to launch on ssh connnection. /usr/bin/master-shell on master,
|
||||
# /usr/bin/runner-shell for workers.
|
||||
# If master and worker are on the same system set to /usr/bin/runner-shell
|
||||
shell=/usr/bin/runner-shell
|
||||
#
|
||||
# Set to "yes" to allow nonpaying users to submit builds
|
||||
allow-free=yes
|
||||
#
|
||||
# Origin URL for the API
|
||||
# Only needed if not run behind a reverse proxy, e.g. for local development.
|
||||
# By default, the API port is 100 more than the web port
|
||||
#api-origin=http://localhost:5102
|
||||
|
||||
#
|
||||
# These config options are only necessary for systems running a build runner
|
||||
[builds.sr.ht::worker]
|
||||
#
|
||||
# Name of this build runner (with HTTP port if not 80)
|
||||
name=runner.codeforge.int
|
||||
#
|
||||
# Path to write build logs
|
||||
buildlogs=/var/log/builds
|
||||
#
|
||||
# Path to the build images
|
||||
images=/var/lib/images
|
||||
#
|
||||
# In production you should NOT put the build user in the docker group. Instead,
|
||||
# make a scratch user who is and write a sudoers or doas.conf file that allows
|
||||
# them to execute just the control command, then update this config option. For
|
||||
# example:
|
||||
#
|
||||
# doas -u docker /var/lib/images/control
|
||||
#
|
||||
# Assuming doas.conf looks something like this:
|
||||
#
|
||||
# permit nopass builds as docker cmd /var/lib/images/control
|
||||
#
|
||||
# For more information about the security model of builds.sr.ht, visit the wiki:
|
||||
#
|
||||
# https://man.sr.ht/builds.sr.ht/installation.md
|
||||
controlcmd=sudo -u docker /var/lib/images/control
|
||||
#
|
||||
# Max build duration. See https://golang.org/pkg/time/#ParseDuration
|
||||
timeout=45m
|
||||
#
|
||||
# Http bind address for serving local build information/monitoring
|
||||
bind-address=127.0.0.1:8080
|
||||
#
|
||||
# Build trigger email
|
||||
trigger-from=user@example.org
|
||||
#
|
||||
# Configure the S3 bucket and prefix for object storage. Leave empty to disable
|
||||
# object storage. Bucket is required to enable object storage; prefix is
|
||||
# optional.
|
||||
s3-bucket=
|
||||
s3-prefix=
|
||||
|
||||
[paste.sr.ht]
|
||||
#
|
||||
# URL paste.sr.ht is being served at (protocol://domain)
|
||||
origin=http://paste.codeforge.int
|
||||
#
|
||||
# Address and port to bind the debug server to
|
||||
#debug-host=0.0.0.0
|
||||
#debug-port=5011
|
||||
#
|
||||
# Configures the SQLAlchemy connection string for the database.
|
||||
connection-string=postgresql://paste:1234@localhost/paste.sr.ht?sslmode=disable
|
||||
#
|
||||
# Set to "yes" to automatically run migrations on package upgrade.
|
||||
migrate-on-upgrade=yes
|
||||
#
|
||||
# paste.sr.ht's OAuth client ID and secret for meta.sr.ht
|
||||
# Register your client at meta.example.org/oauth
|
||||
oauth-client-id=b930097f0d5666fb
|
||||
oauth-client-secret=ee749b58b1ff808f3bc095a7e5ea4f9a
|
||||
#
|
||||
# Origin URL for the API
|
||||
# Only needed if not run behind a reverse proxy, e.g. for local development.
|
||||
# By default, the API port is 100 more than the web port
|
||||
#api-origin=http://localhost:5111
|
||||
20
src/studienarbeit/assets/sourcehut_setup/nginx/graphql.conf
Normal file
20
src/studienarbeit/assets/sourcehut_setup/nginx/graphql.conf
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
real_ip_header X-Forwarded-For;
|
||||
real_ip_recursive on;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Forwarded-Proto https;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
|
||||
if ($request_method = 'OPTIONS') {
|
||||
add_header 'Access-Control-Allow-Origin' '*';
|
||||
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
|
||||
add_header 'Access-Control-Allow-Headers' 'User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
|
||||
add_header 'Access-Control-Max-Age' 1728000;
|
||||
add_header 'Content-Type' 'text/plain; charset=utf-8';
|
||||
add_header 'Content-Length' 0;
|
||||
return 204;
|
||||
}
|
||||
|
||||
add_header 'Access-Control-Allow-Origin' '*';
|
||||
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
|
||||
add_header 'Access-Control-Allow-Headers' 'User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
|
||||
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
|
||||
|
|
@ -0,0 +1,223 @@
|
|||
# Meta
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name meta.codeforge.int;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5000;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /.well-known/oauth-authorization-server {
|
||||
proxy_pass http://127.0.0.1:5000;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5100;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/metasrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Hub
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name codeforge.int;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5014;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5114;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/hubsrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Git
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name git.codeforge.int;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5001;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5101;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/gitsrht;
|
||||
expires 30d;
|
||||
}
|
||||
|
||||
location = /authorize {
|
||||
proxy_pass http://127.0.0.1:5001;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
proxy_set_header X-Original-URI $request_uri;
|
||||
}
|
||||
|
||||
location ~ ^/([^/]+)/([^/]+)/(HEAD|info/refs|objects/info/.*|git-upload-pack).*$ {
|
||||
auth_request /authorize;
|
||||
root /var/lib/git;
|
||||
fastcgi_pass unix:/run/fcgiwrap/fcgiwrap.sock;
|
||||
fastcgi_param SCRIPT_FILENAME /usr/libexec/git-core/git-http-backend;
|
||||
fastcgi_param PATH_INFO $uri;
|
||||
fastcgi_param GIT_PROJECT_ROOT $document_root;
|
||||
fastcgi_read_timeout 500s;
|
||||
include fastcgi_params;
|
||||
gzip off;
|
||||
}
|
||||
}
|
||||
|
||||
# Man
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name man.codeforge.int;
|
||||
|
||||
client_max_body_size 100M;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5004;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5104;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/mansrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Todo
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name todo.codeforge.int;
|
||||
|
||||
client_max_body_size 100M;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5003;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5103;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/todosrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Lists
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name lists.codeforge.int;
|
||||
|
||||
client_max_body_size 100M;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5006;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5106;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/listssrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Paste
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name paste.codeforge.int;
|
||||
|
||||
client_max_body_size 10M;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5011;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5111;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/pastesrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Builds
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name builds.codeforge.int;
|
||||
|
||||
client_max_body_size 100M;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:5002;
|
||||
include web.conf;
|
||||
}
|
||||
|
||||
location /query {
|
||||
proxy_pass http://127.0.0.1:5102;
|
||||
include graphql.conf;
|
||||
}
|
||||
|
||||
location /static {
|
||||
root /usr/lib/$python/site-packages/buildsrht;
|
||||
expires 30d;
|
||||
}
|
||||
}
|
||||
|
||||
# Runner (proxy only local requests)
|
||||
server {
|
||||
include sourcehut.conf;
|
||||
include port80.conf;
|
||||
server_name runner.codeforge.int;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:8080;
|
||||
include web.conf;
|
||||
|
||||
allow 127.0.0.1;
|
||||
deny all;
|
||||
}
|
||||
}
|
||||
10
src/studienarbeit/assets/sourcehut_setup/nginx/port80.conf
Normal file
10
src/studienarbeit/assets/sourcehut_setup/nginx/port80.conf
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
listen 80;
|
||||
listen [::]:80;
|
||||
|
||||
location ^~ /.well-known {
|
||||
root /var/www;
|
||||
}
|
||||
|
||||
location = /robots.txt {
|
||||
root /var/www;
|
||||
}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
set $python "python3.10";
|
||||
set_real_ip_from 127.0.0.0/16;
|
||||
set_real_ip_from 173.195.146.128/25;
|
||||
5
src/studienarbeit/assets/sourcehut_setup/nginx/web.conf
Normal file
5
src/studienarbeit/assets/sourcehut_setup/nginx/web.conf
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
real_ip_header X-Forwarded-For;
|
||||
real_ip_recursive on;
|
||||
proxy_set_header Host $http_host;
|
||||
proxy_set_header X-Forwarded-Proto https;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
48
src/studienarbeit/assets/woodpecker/docker-compose.yml
Normal file
48
src/studienarbeit/assets/woodpecker/docker-compose.yml
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
version: "3"
|
||||
services:
|
||||
woodpecker-server:
|
||||
image: woodpeckerci/woodpecker-server:next
|
||||
restart: unless-stopped
|
||||
networks:
|
||||
- proxy
|
||||
environment:
|
||||
- WOODPECKER_OPEN=true
|
||||
- WOODPECKER_HOST=https://ci.thetadev.de
|
||||
- WOODPECKER_GITEA=true
|
||||
- WOODPECKER_GITEA_URL=https://code.thetadev.de
|
||||
- WOODPECKER_GITEA_CLIENT=48060801-dc04-4361-b0a9-eefbfc6f29d0
|
||||
- WOODPECKER_GITEA_SECRET=gto_wefjljwg4ouio34goi4ui34ui34uighjrfvnerrejrekwhgui34g4
|
||||
- WOODPECKER_AGENT_SECRET=f81909f8e70371af65a6e1c6e77d35d4677c3ed242dcadde032fb27a9c5f9c35
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.docker.network=proxy"
|
||||
- "traefik.http.routers.woodpecker.entrypoints=websecure"
|
||||
- "traefik.http.routers.woodpecker.rule=Host(`ci.thetadev.de`)"
|
||||
- "traefik.http.routers.woodpecker.service=woodpecker"
|
||||
- "traefik.http.services.woodpecker.loadbalancer.server.port=8000"
|
||||
|
||||
# gRPC service
|
||||
- "traefik.http.routers.woodpecker-grpc.entrypoints=websecure"
|
||||
- "traefik.http.routers.woodpecker-grpc.rule=Host(`ci-grpc.thetadev.de`)"
|
||||
- "traefik.http.routers.woodpecker-grpc.service=woodpecker-grpc"
|
||||
- "traefik.http.services.woodpecker-grpc.loadbalancer.server.port=9000"
|
||||
- "traefik.http.services.woodpecker-grpc.loadbalancer.server.scheme=h2c"
|
||||
|
||||
woodpecker-agent:
|
||||
image: woodpeckerci/woodpecker-agent:next
|
||||
command: agent
|
||||
restart: unless-stopped
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
environment:
|
||||
- "WOODPECKER_SERVER=ci-grpc.thetadev.de:443"
|
||||
- "WOODPECKER_AGENT_SECRET=f81909f8e70371af65a6e1c6e77d35d4677c3ed242dcadde032fb27a9c5f9c35"
|
||||
- "WOODPECKER_MAX_PROCS=2"
|
||||
- "WOODPECKER_HOSTNAME=ocloud"
|
||||
- WOODPECKER_GRPC_SECURE=true
|
||||
- WOODPECKER_GRPC_VERIFY=true
|
||||
|
||||
networks:
|
||||
proxy:
|
||||
external: true
|
||||
512
src/studienarbeit/sourcehut_setup.md
Normal file
512
src/studienarbeit/sourcehut_setup.md
Normal file
|
|
@ -0,0 +1,512 @@
|
|||
# Anhang: Installation von Sourcehut
|
||||
|
||||
Da ich im Internet keine vollständige Installationsanleitung für Sourcehut gefunden
|
||||
habe, beschreibe ich hier den vollständigen Installationsvorgang für meine Testinstanz.
|
||||
|
||||
Ich habe Sourcehut wie vom Entwickler empfohlen auf einer Alpine-Linux-VM installiert.
|
||||
Die Sourcehut-Pakete werden auch für Arch und Debian (Sid) angeboten.
|
||||
|
||||
Alle aufgelisteten Befehle müssen als Root-User ausgeführt werden, sofern es nicht
|
||||
anders beschrieben ist.
|
||||
|
||||
## Sourcehut-Repo
|
||||
|
||||
Zuerst muss das Sourcehut-Repository zum Paketmanager des Systems hinzugefügt werden.
|
||||
Die URLs für verschiedene Distributionen sind in der Dokumentation des Projekts
|
||||
angegeben.
|
||||
|
||||
<https://man.sr.ht/packages.md>
|
||||
|
||||
```
|
||||
echo "https://mirror.sr.ht/alpine/v3.17/sr.ht" > /etc/apk/repositories
|
||||
|
||||
wget -q -O /etc/apk/keys/alpine@sr.ht.rsa.pub https://mirror.sr.ht/alpine/alpine@sr.ht.rsa.pub
|
||||
|
||||
apk update
|
||||
```
|
||||
|
||||
## Grundlegende Dienste
|
||||
|
||||
Zu Beginn müssen die grundlegenden Dienste eingerichtet werden: die Postgres-Datenbank,
|
||||
Redis und ein Nginx-Webserver, der als Reverse Proxy zwischen dem Nutzer und den
|
||||
einzelnen Diensten steht.
|
||||
|
||||
Beim Einrichten der Dienste ist zu beachten, dass Alpine Linux OpenRC anstelle des
|
||||
systemd-Init-Systems verwendet und alle neu installierten Dienste manuell aktiviert und
|
||||
gestartet werden müssen.
|
||||
|
||||
```
|
||||
apk add postgresql redis nginx
|
||||
|
||||
rc-service postgresql setup
|
||||
rc-update add postgresql
|
||||
rc-service postgresql start
|
||||
|
||||
rc-update add nginx
|
||||
rc-update add redis
|
||||
rc-service nginx start
|
||||
rc-service redis start
|
||||
```
|
||||
|
||||
Wenn Postgres läuft, kann man die Datenbanken und Nutzer für die einzelnen Dienste
|
||||
erstellen.
|
||||
|
||||
```
|
||||
su postgres
|
||||
psql
|
||||
CREATE USER meta WITH PASSWORD '1234';
|
||||
CREATE DATABASE "meta.sr.ht";
|
||||
ALTER DATABASE "meta.sr.ht" OWNER TO meta;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "meta.sr.ht" TO meta;
|
||||
|
||||
CREATE USER hub WITH PASSWORD '1234';
|
||||
CREATE DATABASE "hub.sr.ht";
|
||||
ALTER DATABASE "hub.sr.ht" OWNER TO hub;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "hub.sr.ht" TO hub;
|
||||
|
||||
CREATE USER git WITH PASSWORD '1234';
|
||||
CREATE DATABASE "git.sr.ht";
|
||||
ALTER DATABASE "git.sr.ht" OWNER TO git;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "git.sr.ht" TO git;
|
||||
|
||||
CREATE USER man WITH PASSWORD '1234';
|
||||
CREATE DATABASE "man.sr.ht";
|
||||
ALTER DATABASE "man.sr.ht" OWNER TO man;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "man.sr.ht" TO man;
|
||||
|
||||
CREATE USER todo WITH PASSWORD '1234';
|
||||
CREATE DATABASE "todo.sr.ht";
|
||||
ALTER DATABASE "todo.sr.ht" OWNER TO todo;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "todo.sr.ht" TO todo;
|
||||
|
||||
CREATE USER lists WITH PASSWORD '1234';
|
||||
CREATE DATABASE "lists.sr.ht";
|
||||
ALTER DATABASE "lists.sr.ht" OWNER TO lists;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "lists.sr.ht" TO lists;
|
||||
|
||||
CREATE USER paste WITH PASSWORD '1234';
|
||||
CREATE DATABASE "paste.sr.ht";
|
||||
ALTER DATABASE "paste.sr.ht" OWNER TO paste;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "paste.sr.ht" TO paste;
|
||||
|
||||
CREATE USER builds WITH PASSWORD '1234';
|
||||
CREATE DATABASE "builds.sr.ht";
|
||||
ALTER DATABASE "builds.sr.ht" OWNER TO builds;
|
||||
GRANT ALL PRIVILEGES ON DATABASE "builds.sr.ht" TO builds;
|
||||
```
|
||||
|
||||
Alle Sourcehut-Dienste werden über eine einzige Datei unter `/etc/sr.ht/config.ini`
|
||||
konfiguriert. Sourcehut stellte jedoch keine vollständige Beispielkonfiguration bereit,
|
||||
weswegen ich meine Konfiguration aus den einzelnen Repositories zusammenkopieren musste.
|
||||
|
||||
- <https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/hub.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/man.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/paste.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/todo.sr.ht/tree/master/item/config.example.ini>
|
||||
- <https://git.sr.ht/~sircmpwn/lists.sr.ht/tree/master/item/config.example.ini>
|
||||
|
||||
[Beispielkonfiguration](./assets/sourcehut_setup/config.ini)
|
||||
|
||||
Folgende Optionen müssen angepasst werden:
|
||||
|
||||
- Die Domains/URLs der Webseiten (in meiner Beispielkonfiguration `*.codeforge.int`).
|
||||
- Datenbank-URLs/Passwörter (Option: `connection-string`)
|
||||
- GPG-Keys (ein GPG-Schlüsselpaar ohne Passwort erstellen und unter `mail/pgp-privkey`,
|
||||
`mail/pgp-pubkey` und `mail/pgp-key-id` angeben)
|
||||
- `service-key`, `network-key`, `webhooks/private-key` (siehe meta.sr.ht)
|
||||
- OAuth-Client-IDs/Secrets (siehe meta.sr.ht)
|
||||
|
||||
Anschließend kann man Nginx so konfigurieren, dass Web-Anfragen an die einzelnen Dienste
|
||||
weitergeleitet werden können. Eine Nginx-Beispielkonfiguration findet sich in
|
||||
[diesem Repository](https://git.sr.ht/~sircmpwn/sr.ht-nginx/tree) auf Sourcehut.
|
||||
|
||||
[Hier](./assets/sourcehut_setup/nginx/nginx_services.conf) befindet sich die angepasste
|
||||
Version (ohne HTTPS), die ich für meine Testinstallation verwendet habe.
|
||||
|
||||
Noch ein Hinweis für Testinstallationen mit internen Domains: Die konfigurierten
|
||||
Domains/URL müssen auf der Maschine, auf der Sourcehut läuft, erreichbar sein. Eventuell
|
||||
müssen diese Domains also in die /etc/hosts-Datei eingetragen werden. Ansonsten
|
||||
funktioniert die OAuth-Authentifizierung sowie das CI-System nicht.
|
||||
|
||||
## Sourcehut-Dienste
|
||||
|
||||
Jede einzelne Sourcehut-Anwendung (git.sr.ht, builds.sr.ht, todo.sr.ht, etc) besteht aus
|
||||
mehreren Diensten. Dazu zählen das Python-Webfrontend, ein in Go geschriebener
|
||||
API-Server und eventuell noch zusätzliche Dienste wie eine Task Queue.
|
||||
|
||||
Die Einrichtung einer Sourcehut-Anwendung erfordert folgende Schritte
|
||||
|
||||
1. Installation des Pakets
|
||||
2. Initialisierung der Datenbank mit dem Skript `<service>-initdb`
|
||||
3. Starten der Dienste
|
||||
|
||||
Bei einigen Diensten sind noch zusätzliche Konfigurationsanpassungen notwendig.
|
||||
|
||||
### meta.sr.ht
|
||||
|
||||
- Web-UI: Port 5000
|
||||
- API: Port 5100
|
||||
|
||||
meta.sr.ht ist der Dienst zur Nutzerverwaltung und Authentisierung und muss deswegen
|
||||
zuerst installiert werden.
|
||||
|
||||
```
|
||||
# Paket installieren
|
||||
apk add meta.sr.ht
|
||||
|
||||
# Datenbank initialisieren
|
||||
metasrht-initdb
|
||||
|
||||
# Schlüssel erzeugen und in die Konfigurationsdatei eintragen
|
||||
# [sr.ht] > service-key
|
||||
srht-keygen service
|
||||
# [sr.ht] > network-key
|
||||
srht-keygen network
|
||||
# [webhooks] > private-key
|
||||
srht-keygen webhook
|
||||
|
||||
# Dienste starten
|
||||
rc-update add meta.sr.ht
|
||||
rc-update add meta.sr.ht-api
|
||||
rc-update add meta.sr.ht-webhooks
|
||||
|
||||
rc-service meta.sr.ht start
|
||||
rc-service meta.sr.ht-api start
|
||||
rc-service meta.sr.ht-webhooks start
|
||||
|
||||
# Admin-Benutzer erstellen
|
||||
metasrht-manageuser -t admin -e thetadev@example.com thetadev
|
||||
|
||||
# Cronjob hinzufügen
|
||||
crontab -e
|
||||
0 0 * * * metasrht-daily
|
||||
```
|
||||
|
||||
Die einzelnen Sourcehut-Dienste verwenden OAuth zur Authentifizierung der Nutzer. Jeder
|
||||
Dienst muss hierfür über eine eigene Client-Konfiguration verfügen. Diese lässt sich
|
||||
über das (Legacy) OAuth-Dashboard unter `meta.<Sourcehut-Domain>/oauth` erstellen.
|
||||
|
||||
|
||||
|
||||
Als _Base Redirect URI_ trägt man die URL des Dienstes mit dem Pfad `oauth/callback`
|
||||
ein. Beispiel: `https://git.codeforge.int/oauth/callback`.
|
||||
|
||||
|
||||
|
||||
Die Client-ID und das Client-Secret, das auf der nächsten Seite angezeigt wird, können
|
||||
nun in die Konfigurationsdatei unter `[<service>.sr.ht]/oauth-client-id` und
|
||||
`[<service>.sr.ht]/oauth-client-secret` eingetragen werden.
|
||||
|
||||
Standardmäßig verlangt Sourcehut nach einer manuellen Einwilligung für die Nutzung eines
|
||||
OAuth-Diensts. Um die internen Sourcehut-Dienste als vertrauenswürdig zu markieren und
|
||||
den Einwilligungsbildschirm für neue Nutzer zu deaktivieren, muss man eine manuelle
|
||||
Änderung an der Datenbank vornehmen und das Feld `preauthorized` für die entsprechenden
|
||||
OAuth-Clients auf `true` setzen.
|
||||
|
||||
```
|
||||
su postgres
|
||||
psql
|
||||
|
||||
\c "meta.sr.ht"
|
||||
UPDATE oauthclient SET preauthorized=true;
|
||||
```
|
||||
|
||||
### hub.sr.ht
|
||||
|
||||
hub.sr.ht fungiert als Startseite für Sourcehut. Hier kann man Projekte erstellen,
|
||||
suchen und aufrufen.
|
||||
|
||||
- Web-UI: Port 5014
|
||||
- API: Port 5114
|
||||
|
||||
```
|
||||
# hub.src.ht (Port: 5014, API-Port: 5114)
|
||||
apk add hub.sr.ht
|
||||
|
||||
hubsrht-initdb
|
||||
|
||||
rc-update add hub.sr.ht
|
||||
rc-update add hub.sr.ht-api
|
||||
|
||||
rc-service hub.sr.ht-api start
|
||||
rc-service hub.sr.ht start
|
||||
```
|
||||
|
||||
### git.sr.ht
|
||||
|
||||
git.sr.ht ist der eigentliche Git-Hosting-Dienst. Sourcehut bietet auch einen Dienst für
|
||||
das Versionskontrollsystem Mercurial an, diesen habe ich jedoch nicht getestet.
|
||||
|
||||
- Web-UI: Port 5001
|
||||
- API: Port 5101
|
||||
|
||||
```
|
||||
# Abhängigkeiten für git-http server installieren
|
||||
apk add git-sr.ht fcgiwrap git-daemon
|
||||
|
||||
gitsrht-initdb
|
||||
```
|
||||
|
||||
Diese Zeilen müssen zur `/etc/ssh/sshd_config` hinzugrfügt werden. Dadurch kann der
|
||||
SSH-Server Nutzer anhand der auf Sourcehut hinterlegten SSH-Zugangsdaten
|
||||
authentifizieren.
|
||||
|
||||
```
|
||||
AuthorizedKeysCommand=/usr/bin/gitsrht-dispatch "%u" "%h" "%t" "%k"
|
||||
AuthorizedKeysCommandUser=root
|
||||
PermitUserEnvironment SRHT_*
|
||||
```
|
||||
|
||||
Da SSH den Login von Nutzern mit nicht gesetztem Passwort verbietet, muss der Account
|
||||
`git` mit einem beliebigen Passwort versehen werden.
|
||||
|
||||
Anschließend muss noch eine Logdatei für das Skript `gitsrht-shell`, dass bei einer
|
||||
SSH-Verbindung aufgerufen wird, erstellt werden.
|
||||
|
||||
```
|
||||
touch /var/log/gitsrht-shell
|
||||
chown git:git /var/log/gitsrht-shell
|
||||
```
|
||||
|
||||
Nachdem alles konfiguriert wurde, kann man den Dienst starten und das Skript
|
||||
`gitsrht-periodic` in den crontab eintragen.
|
||||
|
||||
```
|
||||
rc-update add fcgiwrap
|
||||
rc-update add git.sr.ht
|
||||
rc-update add git.sr.ht-api
|
||||
rc-update add git.sr.ht-webhooks
|
||||
|
||||
rc-service fcgiwrap start
|
||||
rc-service git.sr.ht-webhooks start
|
||||
rc-service git.sr.ht-api start
|
||||
rc-service git.sr.ht start
|
||||
|
||||
# Cronjob hinzufügen:
|
||||
*/20 * * * * gitsrht-periodic
|
||||
```
|
||||
|
||||
### man.sr.ht
|
||||
|
||||
- Web-UI: Port 5004
|
||||
- API: Port 5104
|
||||
|
||||
man.sr.ht ist ein Git-gestütztes Wiki. Der Dienst hängt von git.sr.ht zur Verwaltung der
|
||||
Repositories ab.
|
||||
|
||||
```
|
||||
apk add man.sr.ht
|
||||
|
||||
mansrht-initdb
|
||||
|
||||
rc-update add man.sr.ht
|
||||
rc-update add man.sr.ht-api
|
||||
|
||||
rc-service man.sr.ht-api start
|
||||
rc-service man.sr.ht start
|
||||
```
|
||||
|
||||
### paste.sr.ht
|
||||
|
||||
- Web-UI: Port 5011
|
||||
- API: Port 5111
|
||||
|
||||
paste.sr.ht ist ein simpler Pastebin, mit dem man Codeschnipsel speichern und
|
||||
veröffentlichen kann.
|
||||
|
||||
```
|
||||
apk add paste.sr.ht
|
||||
pastesrht-initdb
|
||||
|
||||
rc-update add paste.sr.ht
|
||||
rc-update add paste.sr.ht-api
|
||||
|
||||
rc-service paste.sr.ht-api start
|
||||
rc-service paste.sr.ht start
|
||||
```
|
||||
|
||||
### builds.sr.ht
|
||||
|
||||
- Web-UI: Port 5002
|
||||
- API: Port 5102
|
||||
|
||||
builds.sr.ht ist der Continuous-Integration-Dienst von Sourcehut.
|
||||
|
||||
Da der Dienst KVM zur Virtualisierung verwendet, muss auf dem Hostsystem _Nested
|
||||
virtualization_ aktiviert werden, sollte der Dienst selbst in einer KVM-gestützten
|
||||
virtuellen Maschine installiert werden:
|
||||
<https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/>
|
||||
|
||||
builds.sr.ht besteht aus zwei Komponenten: dem Master-Server und dem Worker. Der
|
||||
Master-Server verwaltet die Builds, die Worker führen sie aus. Aus Sicherheitsgründen
|
||||
wird empfohlen, die Worker auf einem seperaten System zu installieren. Bei meiner
|
||||
Testinstallation habe ich jedoch beide Komponenten auf dem selben System installiert.
|
||||
|
||||
Zuerst installiert man die erforderlichen Pakete und initialisiert die Datenbank:
|
||||
|
||||
```
|
||||
# Master-Server
|
||||
apk add builds.sr.ht
|
||||
# Worker-Server
|
||||
builds.sr.ht-worker builds.sr.ht-images
|
||||
|
||||
buildsrht-initdb
|
||||
```
|
||||
|
||||
Der Nutzer `builds` muss genauso wie der git-Nutzer mit einem beliebigen Password
|
||||
versehen werden, um den SSH-Zugriff auf fehlgeschlagene Builds zu ermöglichen.
|
||||
|
||||
Anschließend kann man den Master-Server starten
|
||||
|
||||
```
|
||||
rc-update add builds.sr.ht
|
||||
rc-update add builds.sr.ht-api
|
||||
|
||||
rc-service builds.sr.ht-api start
|
||||
rc-service builds.sr.ht start
|
||||
```
|
||||
|
||||
Der Worker benutzt standardmäßig eine QEMU-Installation in einem Docker-Container, um
|
||||
die Build-VMs zu betreiben. Deswegen muss man zuerst Docker installieren und starten.
|
||||
|
||||
Zusätzlich sollte man einen neuen Benutzer mit dem Namen `docker` anlegen und der
|
||||
Docker-Gruppe hinzufügen. Dann konfiguriert man sudo so, dass der `builds`-Nutzer das
|
||||
`/var/lib/images/control`-Skript zum Start der Buildmaschinen als `docker`-Nutzer
|
||||
aufrufen kann. Auf diese Weise muss man dem Build-Nutzer keine vollen Root- oder
|
||||
Docker-Rechte geben.
|
||||
|
||||
```
|
||||
apk add docker
|
||||
rc-update add docker
|
||||
rc-service docker start
|
||||
|
||||
sudo adduser -SDH docker docker
|
||||
|
||||
visudo
|
||||
# Diese Zeile in die sudoers-Datei eintragen
|
||||
builds ALL=(docker) NOPASSWD: /var/lib/images/control
|
||||
```
|
||||
|
||||
```
|
||||
cd /var/lib/images
|
||||
docker build -t qemu qemu/Dockerfile .
|
||||
```
|
||||
|
||||
Als nächstes muss man die VM-Images bauen. Im Ordner `/var/lib/images` befinden sich
|
||||
Skripte für eine Vielzahl von Betriebssystemen und CPU-Architekturen.
|
||||
|
||||
Ich habe zum Testen das Alpine 3.17-Image in einem Docker-Container gebaut. Dazu musste
|
||||
ich zunächst eine kleine Annpassung am Buildskript vornehmen. Das Skript unter
|
||||
`/var/lib/images/alpine/genimg` enthält den Befehl `modprobe nbd max_part=16`, der in
|
||||
einem Docker-Container nicht ausgeführt werden kann. Dieser Befehl muss deshalb
|
||||
auskommentiert werden und stattdessen vorher auf dem Hostsystem ausgeführt werden.
|
||||
|
||||
Anschließend kann man das Image bauen:
|
||||
|
||||
```
|
||||
modprobe nbd max_part=16
|
||||
docker run -it --rm --privileged -v /var/lib/images:/images alpine:3.17
|
||||
|
||||
# Im Docker-Container
|
||||
cd /images/alpine/3.17
|
||||
apk add qemu-img sfdisk syslinux e2fsprogs
|
||||
./genimg
|
||||
```
|
||||
|
||||
Mit der Datei `/etc/image-control.conf` kann der Worker konfiguriert werden
|
||||
(zugewiesener Arbeitsspeicher, Methode der Virtualisierung).
|
||||
|
||||
```
|
||||
MEMORY=4096
|
||||
default_means=docker
|
||||
```
|
||||
|
||||
Nachdem der Worker konfiguriert wurde, kann man ihn mit dem Skript
|
||||
`/var/lib/images/control` testen.
|
||||
|
||||
Hinweis: wenn der Container nicht startet, sollte man prüfen, ob das System genug RAM
|
||||
zum Start der VM zur Verfügung hat.
|
||||
|
||||
```
|
||||
./control alpine/latest boot x86_64 12345
|
||||
docker ps # Prüfen, ob der Container gestartet wurde
|
||||
# Über die SSH-Verbindung kann man nun Befehle auf der Build-VM ausführen
|
||||
ssh -p 12345 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no build@localhost
|
||||
./control alpine/latest cleanup 12345
|
||||
```
|
||||
|
||||
Jetzt kann der Worker gestartet werden:
|
||||
|
||||
```
|
||||
# Start worker
|
||||
rc-update add builds.sr.ht-worker
|
||||
rc-service builds.sr.ht-worker start
|
||||
```
|
||||
|
||||
### todo.sr.ht
|
||||
|
||||
- Web-UI: Port 5003
|
||||
- API: Port 5103
|
||||
|
||||
```
|
||||
apk add todo.sr.ht
|
||||
```
|
||||
|
||||
Im Gegensatz zu den anderen Diensten konnte ich die Datenbank für den todo-Dienst nicht
|
||||
mit `todosrht-initdb` erfolgreich initialisieren. Offenbar fehlten in diesem Skript
|
||||
bestimmte Datenbankobjekte, sodass die Anwendung Fehler lieferte. Stattdessen habe ich
|
||||
die `schema.sql`-Datei aus dem sourcehut-Repository verwendet.
|
||||
|
||||
```
|
||||
wget "https://git.sr.ht/~sircmpwn/todo.sr.ht/blob/master/schema.sql"
|
||||
psql -U todo -d todo.sr.ht -f schema.sql
|
||||
todo-migrate stamp head
|
||||
```
|
||||
|
||||
Anschließend können die Dienste gestartet werden.
|
||||
|
||||
Hinweis: Der LMTP-Dienst ist dafür da, E-Mails zu empfangen, sodass man auf Issues per
|
||||
Mail antworten kann. Hierfür ist ein Mailserver nötig, weswegen ich diesen Dienst in
|
||||
meiner Testinstallation nicht vollständig konfigurieren konnte.
|
||||
|
||||
```
|
||||
rc-update add todo.sr.ht
|
||||
rc-update add todo.sr.ht-api
|
||||
rc-update add todo.sr.ht-lmtp
|
||||
rc-update add todo.sr.ht-webhooks
|
||||
|
||||
rc-service todo.sr.ht-webhooks start
|
||||
rc-service todo.sr.ht-lmtp start
|
||||
rc-service todo.sr.ht-api start
|
||||
rc-service todo.sr.ht start
|
||||
```
|
||||
|
||||
### lists.sr.ht
|
||||
|
||||
- Web-UI: Port 5006
|
||||
- API: Port 5106
|
||||
|
||||
lists.sr.ht ist der Mailingslisten-Dienst für Sourcehut. Mangels eines eigenen
|
||||
Mailservers konnte ich diesen Dienst in meiner Test-VM nicht einrichten.
|
||||
|
||||
Eine Anleitung für die Mail-Konfiguration findet sich hier:
|
||||
<https://man.sr.ht/lists.sr.ht/configuration.md>
|
||||
|
||||
```
|
||||
listssrht-initdb
|
||||
|
||||
rc-update add lists.sr.ht
|
||||
rc-update add lists.sr.ht-api
|
||||
rc-update add lists.sr.ht-lmtp
|
||||
rc-update add lists.sr.ht-process
|
||||
rc-update add lists.sr.ht-webhooks
|
||||
|
||||
rc-service lists.sr.ht-webhooks start
|
||||
rc-service lists.sr.ht-process start
|
||||
rc-service lists.sr.ht-lmtp start
|
||||
rc-service lists.sr.ht-api start
|
||||
rc-service lists.sr.ht start
|
||||
```
|
||||
Loading…
Reference in a new issue