Neu in 0.4.22
CI für ein Repository einrichten
Öffne CI/CD in der Navigationsleiste. Diese Version richtet Continuous Integration ein; sie stellt deine Anwendung nicht bereit.
Die folgenden Bedienelemente sind mit ihren Namen aus der englischen Oberfläche angegeben.
Vor dem Start
Ein bezahlter Tarif und ein Repository mit Commits
Melde dich unter Account mit einem bezahlten Tarif an; ein Platz in einem bezahlten Team-, Business- oder Enterprise-Team zählt, eine Testphase jedoch nicht. Die Einrichtung benötigt einen erreichbaren Termiyo-Server mit den CI-Vorlagen für 0.4.22. Pushe einen ersten Commit in dein Repository, bevor du CI einrichtest.
11 Projekttypen
Build it as bietet Node.js, Python, Go, Rust, Java (Maven), Java (Gradle), Ruby, PHP, .NET, Docker image und A blank starting point. Die Erkennung für GitHub und GitLab liest Dateinamen auf der obersten Ebene des Repositories; prüfe die Auswahl und wähle bei mehreren Treffern einen Typ. Die leere Ausgangsvorlage enthält einen Platzhalterschritt, den du ersetzen musst.
GitHub
1. Ein Token vorbereiten
Wähle GitHub und drücke Open GitHub’s token page. Verwende ein auf das Repository beschränktes, fein abgestuftes persönliches Zugriffstoken: Contents, Workflows und Pull requests benötigen Read and write; Actions und Metadata benötigen Read. Setze den Ablauf auf höchstens 90 Tage. Unterstützt wird nur github.com über api.github.com; GitHub Enterprise wird nicht unterstützt.
2. Speichern und prüfen
Wähle Saved token oder drücke Save a new token, fülle Name und Paste the token aus und drücke Save to key box. Gib unter Repository owner/name oder den github.com-Link ein und drücke Check. Du kannst auch List repositories this token can see verwenden.
3. Vorschau prüfen und Pull Request öffnen
Wähle Build it as, drücke Show the file, prüfe die Datei und drücke Set up CI. Termiyo committet .github/workflows/termiyo-ci.yml auf termiyo/ci-setup und öffnet einen Pull Request. Mit Open in browser kannst du ihn prüfen und zusammenführen. CI kann bereits für den Pull Request laufen; der Standardbranch bleibt bis zur Zusammenführung unverändert.
GitLab
1. Projekt angeben und Token vorbereiten
Wähle GitLab. Gib unter Project group/project für gitlab.com oder die vollständige HTTPS-Projektadresse deines eigenen GitLab ein und drücke Open GitLab’s token page. Verwende ein persönliches oder projektbezogenes Zugriffstoken mit dem Geltungsbereich api; dieser erlaubt alles, was sein Eigentümer tun kann. Wähle daher eine kurze Laufzeit und widerrufe das Token nach der Einrichtung.
2. Projekt und Runner prüfen
Wähle Saved token oder verwende Save a new token → Save to key box und drücke Check. Wähle Build it as. Falls kein Runner verfügbar ist, aktiviere vor der Zusammenführung gemeinsame Runner oder registriere einen Projekt-Runner; das Panel meldet auch, wenn das Token die Verfügbarkeit eines Runners nicht feststellen kann.
3. Vorschau prüfen und Merge Request öffnen
Drücke Show the file, prüfe die Datei und drücke Set up CI. Termiyo committet .gitlab-ci.yml auf termiyo/ci-setup und öffnet einen Merge Request. Mit Open in browser kannst du ihn prüfen und zusammenführen; der Standardbranch bleibt bis dahin unverändert.
Giti: Repos on a host
1. Den Host prüfen
Verbinde dich mit dem SSH-Host deines Giti-Repositories und wähle Repos on a host. Dieser Runner benötigt Linux auf x86_64 oder ARM64, git und ein für das SSH-Konto nutzbares Docker sowie curl oder wget, tar, sha256sum oder shasum und timeout. Termiyo installiert Docker nicht; wende dich an den Hostadministrator oder verwende Rootless Docker.
2. Installieren und aktivieren
Drücke Install the CI runner. Termiyo lädt nektos/act 0.2.89 nach ~/.termiyo/bin herunter und prüft dessen SHA-256 vor dem Entpacken oder Ausführen. Wähle für das Repository Build it as und drücke Turn CI on. Ein vorhandener post-receive-Hook eines anderen Werkzeugs bleibt unverändert und verhindert die automatische Einrichtung.
3. Zusammenführen, pushen und Ergebnis lesen
Falls Termiyo den Workflow-Branch termiyo/ci erstellt hat, kopiere die angezeigten Befehle mit Copy und führe sie in deiner Arbeitskopie auf dem Standardbranch aus, um den Branch zusammenzuführen und zu pushen. Danach führt der Host .github/workflows/termiyo-ci.yml nach Pushes des Eigentümers mit act in Docker aus; Pushes freigeschalteter Teammitglieder starten niemals CI. Lies die Ergebnisse mit Refresh und Log und deaktiviere den Hook mit Turn CI off.
Ressourcen auf deinem Host
Jeder Lauf hat ein Zeitlimit von 30 Minuten. Termiyo fordert von Docker das Bridge-Netzwerk, keinen Docker-Socket im Job, keine neuen Privilegien und Grenzen von 2 CPUs, 4 GB Arbeitsspeicher und 512 Prozessen an; die Durchsetzung hängt vom Docker des Hosts ab. Beim ersten Lauf wird ein 2,3 GB großes Image heruntergeladen.
Grenzen und Prüfung
Vorhandene Workflows und Tarife
Bei GitHub und GitLab überschreibt Termiyo niemals die Zieldatei des Workflows; wenn .gitlab-ci.yml vorhanden ist, bietet es eine Vorlage zur manuellen Zusammenführung an. Der bezahlte Tarif deckt die Einrichtung in Termiyo ab: Das Lesen von Läufen ist nicht tarifgebunden und bereits eingerichtete CI läuft nach Tarifende weiter. Vorlagen kommen vom Termiyo-Server und müssen den in der App festgelegten Fingerabdrücken entsprechen.
Bisherige Prüfung
Die Einrichtung für GitHub und GitLab wurde mit Nachbildungen der Dienste getestet, nicht mit echten Konten. Giti CI hat einen echten Lauf auf einem x86_64-Host abgeschlossen. Die Bereitstellung von Anwendungen ist in dieser Version nicht implementiert.