OpenTag selbst hosten: Slack- und GitHub-Mentions

Was OpenTag bei einer Erwähnung eines Agenten macht

OpenTag wandelt eine @mention in einem Slack-Thread oder einem GitHub-Issue in einen Lauf eines Coding-Agenten auf einem Rechner um, den Sie selbst verwalten. Jemand kommentiert @opentag investigate this in einem Issue. Ein Listener empfängt das Plattformereignis, prüft dessen Signatur, ordnet die Erwähnung einem verknüpften Projekt zu, startet einen Coding-Agenten gegen einen lokalen Checkout und veröffentlicht das Ergebnis im selben Thread.

Das Projekt steht unter der MIT-Lizenz und befindet sich unter amplifthq/opentag. Im August 2026 ist die neueste markierte Version v0.9.0, veröffentlicht am 28. Juli 2026; sie wird als npm-Paket ausgeliefert. Es gibt kein offizielles Container-Image. Daher müssen Sie die npm-Version festlegen. Jeder folgende Befehl legt sie fest.

Durch die GitHub-Seite wird daraus ein VPS-Projekt und kein Laptop-Projekt. GitHub übermittelt Repository-Ereignisse, indem es eine HTTP-Anfrage an eine URL sendet, die Sie einmal registrieren. Diese URL muss daher auch am nächsten Tag unter derselben Adresse erreichbar sein.

Die vier Komponenten

Der Listener empfängt Plattformereignisse. Jede Plattform hat einen eigenen Listener. Der GitHub-Listener ist ein HTTP-Endpunkt auf Port 3050 unter dem Pfad /github/webhooks. Der Listener der Slack Events API läuft auf Port 3040 unter /slack/events. Slack kann auch im Socket Mode betrieben werden. Dabei öffnet die Anwendung eine ausgehende WebSocket-Verbindung und benötigt keinen eingehenden Port.

Der Dispatcher koordiniert den Ablauf. Er überwacht standardmäßig Port 3030, speichert den Ausführungsstatus in einer lokalen Datenbankdatei, die durch OPENTAG_DATABASE_PATH festgelegt wird, und protokolliert für jede Ausführung einen Audit-Trail. Dieser Port darf niemals von außerhalb des Systems erreichbar sein.

Der Runner ist der lokale Daemon. Er fragt regelmäßig nach neuen Aufgaben, übernimmt eine Ausführung, hält dafür eine Lease und sendet standardmäßig alle 15 Sekunden einen Heartbeat, solange die Ausführung aktiv ist. Er lehnt jede übernommene Ausführung ab, deren Projektziel fehlt oder außerhalb der Allowlist in seiner eigenen Konfiguration liegt. Diese Prüfung verhindert, dass ein GitHub-Ereignis Ihren Agenten auf ein Repository verweist, das Sie nie zugeordnet haben.

Der Executor ist der Coding-Agent selbst. OpenTag startet ihn über ACP (Agent Client Protocol), ein über die Standardeingabe und -ausgabe übertragenes JSON-RPC-Protokoll. Der Agent läuft daher als untergeordneter Prozess in einem Arbeitsverzeichnis, das OpenTag ihm übergibt. Zu den integrierten Namen gehören echo, codex, claude-code, cursor, opencode, hermes und openclaw. Beginnen Sie mit echo, dem Executor, den die Beispielkonfiguration verwendet. Damit lässt sich der gesamte Ablauf prüfen, bevor ein Modell Ihren Code verändert. Wenn die Schleife, die eine Eingabe liest, Tools aufruft und entscheidet, wann sie fertig ist, für Sie noch eine Blackbox ist, hilft zuerst selbst eine kleine Agentenschleife zu schreiben, die Fehlerzustände in dieser Pipeline deutlich leichter zu erkennen.

Die Reihenfolge ändert sich nie: Plattformereignis, Signaturprüfung, Ausführungsdatensatz, Übernahme, Agent, Antwort im Thread.

Warum ein Laptop und ein Tunnel nicht ausreichen

Die GitHub-Einrichtungsanleitung weist Sie an, ngrok http 3050 auszuführen und den Tunnel-Host in den Repository-Webhook einzutragen. Das funktioniert in den ersten zehn Minuten. Der Host eines kostenlosen Tunnels ändert sich bei jedem Neustart des Prozesses und ist nicht mehr erreichbar, sobald der Laptop in den Ruhezustand wechselt. GitHub behält die alte Payload-URL und versucht weiterhin, sie zu verwenden. Dadurch füllt sich die Registerkarte „Recent Deliveries“ in den Webhook-Einstellungen mit Fehlern, während der Thread stumm bleibt. Eine Woche lang bemerkt das niemand, weil ein Webhook, der nichts tut, genauso aussieht wie ein Bot, den niemand erwähnt hat.

Ein VPS behebt die beiden Ursachen. Der DNS-Name ändert sich nicht. Die einmal eingetragene Payload-URL bleibt daher korrekt. Die Maschine wechselt nicht in den Ruhezustand. Dadurch erhält ein Kommentar um 02:00 eine Antwort. Richten Sie das System zuerst ordnungsgemäß ein: die ersten zehn Minuten auf einem neuen VPS behandeln den Anmeldebenutzer und die Firewall, von denen diese Anleitung ausgeht.

Slack ist die Ausnahme. Im Socket Mode baut Slack ausgehende Verbindungen auf und benötigt keine öffentliche URL. Eine reine Slack-Bereitstellung kann daher geschlossen bleiben. Für GitHub gibt es keine entsprechende Funktion. Repository-Webhooks verwenden eingehendes HTTP. Das erfordert einen öffentlichen Endpunkt und damit TLS (Transport Layer Security) sowie eine Signaturprüfung.

OpenTag unter Ubuntu aus einem festgelegten Release selbst hosten

OpenTag v0.9.0 benötigt Node.js 22 oder neuer. Ubuntu 24.04 liefert im eigenen Repository Node 18 aus. Installieren Sie Node.js daher aus NodeSource.

curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v muss v22 oder höher ausgeben. Unter Node 20 gibt die Installation eine EBADENGINE-Warnung aus. Die CLI kann anschließend beim Start fehlschlagen.

Geben Sie dem Dienst ein eigenes Konto. Der Agent läuft mit den Berechtigungen dieses Benutzers. Verwenden Sie daher weder Ihr Anmeldekonto noch root. Benutzer mit geringsten Rechten auf einem VPS erläutert, warum diese Trennung den zusätzlichen Schritt rechtfertigt.

sudo adduser --disabled-password --gecos "" opentag
sudo loginctl enable-linger opentag
sudo npm install -g @opentag/cli@0.9.0
command -v opentag

command -v opentag sollte einen Pfad wie /usr/bin/opentag ausgeben. Die Linger-Einstellung ist unter Linux wichtig: OpenTag installiert seinen Hintergrunddienst über systemd. Ein Benutzerdienst ohne Linger wird beendet, sobald Ihre SSH-Sitzung geschlossen wird.

Führen Sie die Einrichtung als dieser Benutzer aus.

sudo -iu opentag opentag setup

Das Setup fragt sechs Dinge ab: die Sprache der CLI, die lokale Listening-Adresse, den Coding-Agent, das lokale Projekt, an dem gearbeitet werden soll, die zu speichernden Zugangsdaten der Plattform und die Betriebsart. Belassen Sie die Listening-Adresse bei 127.0.0.1, weil nginx TLS beendet und Anfragen dorthin weiterleitet. Die Listener müssen daher niemals von außen erreichbar sein. Für GitHub werden außerdem das Repository im Format owner/repo, die Berechtigung zum Öffnen von Pull Requests, der Webhook-Port (standardmäßig 3050) und das Token abgefragt. Wählen Sie am Ende den Modus für den Hintergrunddienst. Wenn bereits eine Konfiguration vorhanden ist und Sie den Dienst ohne Eingabeaufforderungen installieren möchten, erledigt opentag setup --service dies.

Die Konfiguration wird unter /home/opentag/.config/opentag/config.json abgelegt, der Laufzeitstatus unter /home/opentag/.local/state/opentag. Prüfen Sie diese Schlüssel nach dem Schreiben der Datei manuell.

{
  "runnerId": "runner_local",
  "dispatcherUrl": "http://localhost:3030",
  "runnerToken": "...",
  "approvalMode": "ask",
  "repositories": []
}

Bevorzugen Sie runnerToken, das auf den Runner begrenzte Bearer-Token, gegenüber dem älteren gemeinsam verwendeten pairingToken. Die Konfigurationsdatei enthält Zugangsdaten im Klartext, sofern Sie sie nicht durch eine Secret-Referenz ersetzen. Diese liest den Wert beim Start aus der Umgebung oder aus einer Datei auf dem Datenträger. In beiden Fällen ist diese Datei die sensibelste Datei auf dem System: Sie sollte den Modus 600 haben, opentag gehören und sich niemals in einem git-Repository befinden. Die weitergehende Begründung finden Sie unter Secrets aus AI-Agenten heraushalten.

Prüfen Sie die Installation, bevor Sie etwas nach außen freigeben.

sudo -iu opentag opentag doctor
sudo -iu opentag opentag status

opentag doctor prüft den Dispatcher, die Bindings, die Checkouts und die Executoren. opentag status gibt die Konfiguration und den Laufzeitstatus aus. Sobald Runs vorhanden sind, kann der Befehl auf einen einzelnen Run begrenzt werden. Beheben Sie alle von doctor gemeldeten Probleme, bevor Sie eine Plattform auf dieses System verweisen.

TLS vorschalten und nur zwei Pfade öffnen

nginx übernimmt die TLS-Terminierung und leitet genau zwei Pfade weiter. Für alle anderen Pfade wird 404 zurückgegeben. Ein Scanner, der den Host findet, erfährt dadurch nichts über die dahinter laufenden Dienste.

Schreiben Sie unter /etc/nginx/sites-available/opentag einen einfachen Server-Block für Port 80 mit den beiden folgenden Locations. Lassen Sie anschließend Certbot den TLS-Teil ergänzen.

sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/opentag /etc/nginx/sites-enabled/opentag
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d opentag.example.com

nginx -t gibt syntax is ok und test is successful aus. Dieser Befehl ist die einzige Kontrolle zwischen einem Tippfehler und einem Reload, durch den die Website ausfällt. Certbot unter Ubuntu 24.04 mit nginx behandelt die Erneuerung und die Fälle, in denen eine ACME-Challenge (automatische Zertifikatsverwaltungsumgebung) fehlschlägt. Der fertige Block sieht so aus.

server {
    listen 443 ssl;
    server_name opentag.example.com;

    ssl_certificate     /etc/letsencrypt/live/opentag.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/opentag.example.com/privkey.pem;

    client_max_body_size 2m;

    location = /github/webhooks {
        proxy_pass http://127.0.0.1:3050;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location = /slack/events {
        proxy_pass http://127.0.0.1:3040;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
        return 404;
    }
}

Das = in location = /github/webhooks ist eine exakte Übereinstimmung. proxy_pass ohne weitere Zeichen nach dem Port leitet die ursprüngliche URI unverändert weiter. Wenn Sie = entfernen, wird jeder Pfad unter /github/webhooks/ ebenfalls weitergeleitet. Das stellt mehr Angriffsfläche bereit, als der Listener benötigt.

Die Firewall bleibt restriktiv.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Die Ports 3030, 3040 und 3050 werden niemals geöffnet. Prüfen Sie, ob sie an Loopback und nicht an jede Schnittstelle gebunden sind.

sudo ss -tlnp

Jede OpenTag-Zeile sollte 127.0.0.1:3030 oder ähnlich lauten. Eine Zeile mit 0.0.0.0:3050 bedeutet, dass der Listener sich dem gesamten Internet anbietet und nur ufw ihn noch blockiert. Ein einziger Fehler in der Firewall-Konfiguration würde dadurch einen offenen Agent-Trigger erzeugen. Grundlagen der ufw-Firewall erklärt, was diese standardmäßige Ablehnung tatsächlich bewirkt.

Zwei Prüfungen bestätigen den Zugangspunkt. curl -I https://opentag.example.com/ gibt 404 von nginx zurück. Das zeigt, dass das Zertifikat gültig ist und der Catch-all geschlossen bleibt. Eine Anfrage an /slack/events oder /github/webhooks ohne Signatur darf niemals 200 zurückgeben.

Jede Signatur prüfen, weil die URL öffentlich ist

Jeder kann die Payload-URL finden. Sie steht in den Repository-Einstellungen, im Browserverlauf oder in einem Screenshot, der in ein Ticket eingefügt wurde. Die Signatur ist das einzige Merkmal, das eine echte GitHub-Zustellung von einer manuell eingegebenen Anfrage unterscheidet.

GitHub signiert jede Zustellung mit dem Webhook-Secret und sendet das Ergebnis im Header x-hub-signature-256. OpenTag prüft diesen Header gegen platforms.github.webhookSecret. Die Hardening-Hinweise des Projekts formulieren die Regel eindeutig: Nicht signierte Source-Ereignisse auf /github/webhooks dürfen nicht akzeptiert werden. Slack signiert jede Anfrage mit SLACK_SIGNING_SECRET und fügt einen Zeitstempel hinzu. Dadurch kann ein abgefangener Body nicht Stunden später erneut verwendet werden.

Das Weglassen dieser Prüfung ist kein geringes Risiko. Ein nicht verifizierter Endpunkt akzeptiert eine manuell erstellte issue_comment-Payload mit @opentag. OpenTag startet dann mit Ihrem Token in Ihrem Checkout einen Coding-Agenten und führt Anweisungen eines Fremden aus. Die Antwort wird an den Thread gesendet, den die gefälschte Payload angibt.

OpenTag ergänzt zwei weitere Schutzebenen. Source-Zustellungen werden anhand der Delivery-ID erfasst. Eine erneute Zustellung desselben Ereignisses startet daher keinen zweiten Lauf. Runner-Aufrufe akzeptieren Idempotency Keys. Bei der Wiederholung eines Aufrufs wird dadurch Erfolg gemeldet, ohne ein weiteres Audit-Ereignis anzuhängen.

Rate Limits können konfiguriert werden und sollten aktiviert sein. OPENTAG_RATE_LIMIT_WINDOW_MS und OPENTAG_RATE_LIMIT_MAX_REQUESTS begrenzen die Anfragerate, OPENTAG_MAX_REQUEST_BODY_BYTES begrenzt die Größe des Bodys, und eine zu große Payload wird mit 413 request_body_too_large abgewiesen. OPENTAG_RATE_LIMIT_DISABLED=true ist für die lokale Entwicklung vorgesehen und hat auf einem öffentlich erreichbaren Server nichts zu suchen. Eine weitere Regel aus denselben Hinweisen: Eine öffentliche Relay-URL muss HTTPS verwenden. Die CLI erlaubt unverschlüsseltes HTTP nur für localhost.

Welche Token-Bereiche benötigt der Bot tatsächlich?

Auf GitHub verwendet OpenTag ein feingranulares Personal Access Token anstelle einer GitHub App. In der Dokumentation steht, dass der App-Weg geplant ist und heute nicht die standardmäßige CLI-Konfiguration darstellt. Daraus ergibt sich eine wichtige Konsequenz: Der Bot kommentiert als die Person, die das Token erstellt hat. Erstellen Sie es unter einem Konto, dessen Name in jeder Triage-Antwort erscheinen darf.

Beschränken Sie die Berechtigungen genau wie im Einrichtungsleitfaden. Wählen Sie Only select repositories und legen Sie ein Repository fest. Erteilen Sie Issues: Read and write sowie Pull requests: Read and write. Das reicht aus, um eine Erwähnung zu lesen und im Thread zu antworten.

Beachten Sie, was fehlt: Schreibzugriff auf den Code. OpenTag pusht keine Branches, solange preparePullRequestBranch nicht auf true gesetzt ist. Zusätzlich gibt es githubApplyToken, damit das Token zum Schreiben von Code nicht dasselbe ist wie das Token zum Schreiben von Kommentaren. Halten Sie diese Token getrennt und lassen Sie das Schreib-Token deaktiviert, bis der Lese-und-Kommentierpfad einige Wochen lang ausgeführt wurde.

Vermeiden Sie ein Token mit Contents: Read and write für All repositories. Jede Person, die in einem dieser Repositories kommentieren kann, kann dann einen Agenten mit Commit-Berechtigungen steuern. Im Audit-Protokoll erscheint dabei der Besitzer des Tokens als handelnde Person. Erweitern Sie den Geltungsbereich jeweils nur um ein Repository, nachdem sich der Agent bewährt hat.

Auf Slack lauten die Bot-Bereiche app_mentions:read, chat:write, reactions:write und channels:history. Private Channels benötigen außerdem groups:history sowie ein Abonnement für das Ereignis message.groups. Für Socket Mode ist ein App-Level-Token mit connections:write erforderlich, also eines, das mit xapp- beginnt. channels:history liest den Nachrichtenverlauf in den öffentlichen Channels, zu denen der Bot hinzugefügt wurde. Fügen Sie den Bot daher nur den gewünschten Channels hinzu, nicht allen.

Einen Vorgang Ende zu Ende ausführen

Der Webhook wird zuerst eingerichtet. Öffnen Sie im Repository Settings, anschließend Webhooks und dann Add webhook. Die Payload-URL ist https://opentag.example.com/github/webhooks, der Inhaltstyp ist application/json und das Secret ist das von der Einrichtung erzeugte. Abonnieren Sie Issue comments und Pull request review comments, sonst nichts.

GitHub sendet sofort nach dem Speichern eine Ping-Zustellung. Öffnen Sie Recent Deliveries und prüfen Sie, ob die Anfrage den Server überhaupt erreicht hat. Ein 502 bedeutet dort, dass nginx den Listener nicht erreichen konnte. Das ist ein lokales Problem und kein GitHub-Problem.

Testen Sie die Einrichtung jetzt. Öffnen Sie ein Issue, das einen Fehler beschreibt, und kommentieren Sie:

@opentag triage this. Reproduce the report against the current main branch, then reply with the file and function most likely responsible, plus the test you would write first.

Das sollte in dieser Reihenfolge passieren. Recent Deliveries protokolliert die issue_comment-Zustellung mit einer 2xx-Antwort. Der Dispatcher protokolliert einen Lauf. Der Runner übernimmt ihn und beginnt mit den Heartbeats. Der Executor öffnet den Checkout und führt die Arbeit aus. Die Antwort erscheint als Kommentar im selben Issue-Thread. sudo -iu opentag opentag status zeigt den laufenden Lauf an. Dadurch können Sie ihn beobachten, statt das Ergebnis zu erraten.

Setzen Sie approvalMode vor dem ersten echten Lauf auf ask. Im Modus ask wird der Lauf angehalten und wartet auf eine Person, bevor er Änderungen am Zustand vornimmt. Die Modi auto und autonomous sind ebenfalls vorhanden. Sie sind später sinnvoll, wenn Sie die Transkripte eines Repositorys einen Monat lang gelesen haben.

Auf der Slack-Seite beginnt derselbe Lauf mit /bind owner/repo im Channel und anschließend mit einer Erwähnung. Der Bot antwortet außerdem auf /help, /status, /doctor, /stop und /unbind confirm. Beschränken Sie mit OPENTAG_SLACK_BINDING_ADMIN_USER_IDS, einer durch Kommas getrennten Liste von Slack-Benutzer-IDs, wer Bindings ändern darf. Ein Binding ordnet einen öffentlichen Channel einem Checkout auf Ihrem Server zu.

Triage ist ein guter erster Ablauf, weil dabei gelesen und nicht geschrieben wird und sich die Antwort leicht bewerten lässt. Review ist der nächste Schritt. Dabei kommentiert der Agent einen Diff statt eines Issues: ein Self-hosted Pull-Request-Review-Agent ist dieselbe Architektur, die auf Pull Requests ausgerichtet ist. Wenn der Agent während der Arbeit auf Ihre eigenen Systeme zugreifen soll, übernehmen das MCP-Server auf einem VPS. Die Websuche ist die andere Funktion, nach der Triage häufig verlangt. Den Agent mit Ihrer eigenen SearXNG-Instanz verbinden hält diese Abfragen auf Hardware, die Sie selbst betreiben. Dafür gibt es einen weiteren Kanal, über den fremder Text den Agent erreicht.

Was passiert, wenn der Agent vor allen anderen falsch liegt?

Das wird passieren. Entscheidend ist, welche Folgen das hat.

Eine falsche Antwort in einem öffentlichen Issue ist ein Kommentar unter einem Namen, den Ihr Team kennt. GitHub sendet ihn sofort nach der Veröffentlichung per E-Mail an alle Abonnenten. Wenn Sie den Kommentar löschen, wird die E-Mail nicht zurückgerufen. Für eine Slack-Benachrichtigung gilt dasselbe. Planen Sie damit, dass die Antwort öffentlich falsch sein kann, statt davon auszugehen, dass sie privat richtig ist.

Vier Entscheidungen begrenzen den Schaden. Sie sind wichtiger als jeder Prompt, den Sie schreiben.

• Führen Sie den Agenten im ask-Modus aus. Dann schlägt der Agent einen Plan vor, eine Person genehmigt ihn, und ein falscher Plan kostet nur einen Klick.
• Belassen Sie preparePullRequestBranch beim Standardwert false. Dann ist das schlimmste Ergebnis eines fehlerhaften Laufs ein falscher Kommentar und nicht ein falscher Branch.
• Binden Sie zunächst ein Repository und einen Channel. Der Runner lehnt jeden Lauf ab, dessen Projektziel außerhalb seiner lokalen Allowlist liegt. Ein nicht gebundenes Repository kann den Agenten daher nicht für sich einsetzen.
• Halten Sie das Token für Kommentare getrennt von jedem Apply-Token. So können Sie Schreibzugriff entziehen, ohne die Triage zu deaktivieren.

Slack bietet den Befehl /stop für einen Lauf, der in die falsche Richtung geht. Jeder Lauf hinterlässt außerdem einen Audit-Eintrag. Dieser enthält die Mention, die den Lauf gestartet hat, und die Aktionen des Agenten. Anhand dieses Eintrags können Sie anschließend nachvollziehen, wo der Fehler aufgetreten ist.

Der soziale Aspekt ist ebenso wichtig wie die Konfiguration. Setzen Sie den Bot in einen Channel, in dem die Beteiligten mit einem Bot rechnen und wissen, dass er falsch liegen kann. Eine selbstsichere falsche Antwort in einem Channel mit vierzig Personen, die davon ausgehen, dass ein Mensch sie geprüft hat, verursacht mehr Aufwand, als die Triage einspart. Schreiben Sie in die Channel-Beschreibung, wer für den Bot verantwortlich ist und wer seine Ausgaben prüft.

Backups, Upgrades und Versions-Pinning

Zwei Pfade enthalten alle relevanten Daten: /home/opentag/.config/opentag/config.json und /home/opentag/.local/state/opentag. Im ersten liegen Ihre Zugangsdaten, im zweiten die Ausführungshistorie und die Datenbankdatei. Sichern Sie beide mit dem Modus 600 und bewahren Sie die Sicherungen außerhalb des Servers auf. Bei einem Verlust müssen Sie Token und Bindings neu erstellen, nicht den Server neu aufbauen.

Upgrades bestehen aus einer Versionsaktualisierung und einem Neustart.

sudo npm install -g @opentag/cli@0.9.0
sudo -iu opentag opentag service stop
sudo -iu opentag opentag service start
sudo -iu opentag opentag doctor

Fixieren Sie die Version, statt @latest zu verfolgen. Diese Software führt mit einem aktiven Token einen Coding-Agent in Ihrem Repository aus. Eine über Nacht veröffentlichte Version wäre daher eine ungeprüfte Änderung daran. Die Security Policy stellt keine Backports bereit. Fehlerbehebungen erscheinen nur in der neuesten Version. Beim Versions-Pinning lesen Sie deshalb das Changelog und aktualisieren bewusst. Das bedeutet nicht, dass Sie dauerhaft bei v0.9.0 bleiben. Die Historie bis Juli 2026 zeigt mehrere Releases pro Monat. Das ist ein guter Grund, vor jeder Versionsaktualisierung die Release Notes zu lesen.

FAQ

Brauche ich einen VPS, um OpenTag auszuführen, oder reicht ein Laptop?

Für Slack allein reicht ein Laptop, weil Socket Mode eine ausgehende WebSocket-Verbindung öffnet und keinen eingehenden Port benötigt. Bei GitHub ist das anders. Repository-Webhooks werden über eingehendes HTTP an eine einmal registrierte URL zugestellt. Daher muss die Adresse gleich bleiben und erreichbar sein, während Sie schlafen. Ein Tunnel-Host aus einem kostenlosen Konto ändert sich bei jedem Neustart. GitHub sendet weiterhin an die alte Adresse. Das erscheint als fehlgeschlagene Zustellung im Tab Recent Deliveries des Repositorys und als ausbleibende Antwort im Thread. Ein VPS mit einem festen DNS-Namen und einem Zertifikat beseitigt beide Probleme.

Welche GitHub-Berechtigungen benötigt OpenTag?

Ein fein granularer persönlicher Zugriffstoken, beschränkt auf Only select repositories, mit Issues: Read and write und Pull requests: Read and write. Damit können Sie eine Erwähnung lesen und im Thread antworten. Schreibzugriff auf den Code ist nicht erforderlich, außer Sie setzen preparePullRequestBranch auf true, damit OpenTag Branches pusht. Zusätzlich gibt es githubApplyToken, sodass der Token für das Schreiben von Code vom Token für Kommentare getrennt bleibt. Vermeiden Sie einen Token für alle Repositorys mit Schreibzugriff auf Inhalte. Jeder, der in eines dieser Repositorys kommentieren kann, könnte damit einen Agenten steuern, der Commits erstellen kann.

Wie stoppe ich einen fehlerhaften Lauf?

Slack verfügt dafür über einen /stop-Befehl. Auf dem Server zeigt opentag status an, was gerade ausgeführt wird. opentag service stop stoppt den Daemon und beendet damit die gesamte Pipeline statt nur eines Laufs. Wenn Sie keinen dieser Befehle benötigen möchten, setzen Sie approvalMode auf ask. Dann werden Läufe angehalten, damit eine Person die Änderungen bestätigt. Lassen Sie preparePullRequestBranch auf false, damit ein fehlerhafter Lauf einen Kommentar statt eines Branches erzeugt.

Warum gibt mein Webhook 502 zurück, während der Thread stumm bleibt?

502 wird von nginx zurückgegeben, nicht von OpenTag. Der Status bedeutet, dass der Proxy den Listener nicht erreichen konnte. /var/log/nginx/error.log zeigt connect() failed (111: Connection refused) while connecting to upstream an. Entweder wurde der Listener gestoppt, oder er verwendet einen anderen Port als in der Zeile proxy_pass angegeben. Führen Sie sudo ss -tlnp aus. Bestätigen Sie, dass auf 127.0.0.1:3050 für GitHub und auf 127.0.0.1:3040 für Slack ein Listener aktiv ist. Führen Sie anschließend opentag doctor für die Bindings und Executoren aus.