Jak samodzielnie hostować OpenTag dla agenta AI

Działanie OpenTag po wzmiance o agencie

OpenTag przekształca wzmiankę @mention w wątku Slack lub zgłoszeniu GitHub w uruchomienie agenta programistycznego na posiadanej przez użytkownika maszynie. Ktoś dodaje komentarz @opentag investigate this w zgłoszeniu. Proces nasłuchujący odbiera zdarzenie platformy, weryfikuje jego sygnaturę, dopasowuje wzmiankę do przypisanego projektu, uruchamia agenta programistycznego w lokalnej kopii repozytorium i publikuje wynik w tym samym wątku.

Projekt jest udostępniony na licencji MIT i znajduje się pod adresem amplifthq/opentag. Według stanu na sierpień 2026 najnowsze wydanie oznaczone tagiem to v0.9.0, opublikowane 28 lipca 2026, dystrybuowane jako pakiet npm. Nie istnieje oficjalny obraz kontenera, dlatego przypina się wersję npm. Każde poniższe polecenie realizuje to przypięcie.

Ze względu na specyfikę integracji z GitHub, projekt ten wymaga VPS zamiast lokalnego laptopa. GitHub dostarcza zdarzenia repozytorium poprzez wysyłanie żądań HTTP na zarejestrowany adres URL, co oznacza, że dany adres musi być dostępny pod tym samym adresem w przyszłości.

Cztery ruchome elementy

Listener odbiera zdarzenia platformy, a każda platforma posiada własny mechanizm. Listener GitHub to punkt końcowy HTTP na porcie 3050 pod ścieżką /github/webhooks. Listener Slack Events API działa na porcie 3040 pod adresem /slack/events. Slack może również działać w trybie Socket Mode, w którym aplikacja otwiera wychodzące połączenie WebSocket i nie wymaga żadnego portu przychodzącego.

Dispatcher pełni rolę koordynatora. Domyślnie nasłuchuje na porcie 3030, przechowuje stan uruchomienia w lokalnym pliku bazy danych określonym przez OPENTAG_DATABASE_PATH oraz rejestruje ścieżkę audytu dla każdego zadania. Żaden zewnętrzny komponent nie powinien mieć dostępu do tego portu.

Runner to lokalny demon. Odpytuje o zadania, przejmuje uruchomienie, utrzymuje jego dzierżawę i domyślnie wysyła sygnał heartbeat co 15 sekund, dopóki proces trwa. Odrzuca każde przejęte zadanie, jeśli docelowy projekt nie istnieje lub znajduje się poza listą dozwolonych (allowlist) w jego konfiguracji. Jest to mechanizm zabezpieczający, który uniemożliwia zdarzeniu z GitHub skierowanie agenta do repozytorium, które nie zostało powiązane.

Executor to właściwy agent programistyczny. OpenTag uruchamia go za pomocą ACP (agent client protocol), protokołu JSON-RPC działającego przez standardowe wejście i wyjście, dzięki czemu agent działa jako proces potomny w katalogu roboczym wskazanym przez OpenTag. Wbudowane nazwy to echo, codex, claude-code, cursor, opencode, hermes oraz openclaw. Należy rozpocząć od echo, czyli executora dostarczanego z przykładową konfiguracją, ponieważ pozwala on zweryfikować poprawność całej ścieżki przed przekazaniem kodu do modelu.

Kolejność działań jest stała: zdarzenie platformy, weryfikacja podpisu, zapis uruchomienia, przejęcie, agent, odpowiedź w wątku.

Dlaczego laptop i tunel to za mało

Przewodnik konfiguracji GitHub zaleca uruchomienie ngrok http 3050 i wklejenie hosta tunelu do webhooka repozytorium. Działa to przez pierwsze dziesięć minut. Darmowy host tunelu zmienia się przy każdym restarcie procesu i przestaje istnieć, gdy laptop przechodzi w stan uśpienia. GitHub zachowuje stary adres URL ładunku (payload URL) i ponawia próby, przez co karta Recent Deliveries w ustawieniach webhooka zapełnia się błędami, podczas gdy wątek pozostaje martwy. Nikt nie zauważa problemu przez tydzień, ponieważ webhook, który nie działa, wygląda dokładnie tak samo jak bot, o którym nikt nie wspomniał.

VPS rozwiązuje dwa problemy, które powodują awarie. Nazwa DNS nie zmienia się, więc wklejony raz adres URL ładunku pozostaje poprawny. Maszyna nie przechodzi w stan uśpienia, więc komentarz dodany o 02:00 otrzyma odpowiedź. Najpierw należy odpowiednio skonfigurować serwer: pierwsze dziesięć minut na nowym VPS opisuje użytkownika logowania oraz zaporę sieciową, które zakłada ten przewodnik.

Slack stanowi wyjątek. W trybie Socket Mode łączy się on na zewnątrz i nie wymaga publicznego adresu URL, więc wdrożenie obsługujące wyłącznie Slacka może pozostać zamknięte. GitHub nie posiada odpowiednika tej funkcji. Webhooki repozytorium to przychodzące żądania HTTP, co oznacza konieczność posiadania publicznego punktu końcowego, a tym samym TLS (transport layer security) oraz weryfikacji podpisu.

Samodzielna instalacja OpenTag na Ubuntu z przypisanej wersji

OpenTag v0.9.0 wymaga Node.js 22 lub nowszego. Ubuntu 24.04 dostarcza Node 18 w swoich repozytoriach, dlatego należy przeprowadzić instalację z 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 musi zwrócić v22 lub wyższą wartość. W przypadku Node 20 instalator wyświetla ostrzeżenie EBADENGINE, a interfejs CLI może ulec awarii po uruchomieniu.

Utwórz dedykowane konto dla usługi. Agent działa z uprawnieniami tego użytkownika, więc nie powinno to być Twoje konto logowania ani root. Artykuł Użytkownicy z minimalnymi uprawnieniami na VPS wyjaśnia, dlaczego ta separacja jest istotna.

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 powinno zwrócić ścieżkę, taką jak /usr/bin/opentag. Ustawienie linger jest kluczowe w systemach Linux: OpenTag instaluje usługę w tle przez systemd, a usługa użytkownika bez włączonego linger zatrzymuje się w momencie zamknięcia sesji SSH.

Uruchom konfigurację jako ten użytkownik.

sudo -iu opentag opentag setup

Instalator wymaga podania sześciu informacji: języka CLI, lokalnego adresu nasłuchiwania, agenta kodującego, lokalnego projektu do pracy, danych uwierzytelniających platformy do zapisania oraz trybu uruchomienia. Pozostaw adres nasłuchiwania na 127.0.0.1, ponieważ nginx wykonuje terminację TLS i przekazuje ruch dalej, więc nasłuchujące usługi nie muszą być dostępne z zewnątrz. W przypadku GitHub wymagane jest podanie repozytorium w formacie owner/repo, zgoda na otwieranie pull requestów, port webhooka (domyślnie 3050) oraz token. Na końcu wybierz tryb usługi działającej w tle. Jeśli posiadasz już konfigurację i chcesz zainstalować usługę bez pytań, użyj opentag setup --service.

Konfiguracja znajduje się w /home/opentag/.config/opentag/config.json, a stan środowiska uruchomieniowego w /home/opentag/.local/state/opentag. Warto sprawdzić te klucze ręcznie po zapisaniu pliku przez instalator.

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

Preferuj runnerToken, czyli token bearer o zasięgu runnera, zamiast starszego współdzielonego pairingToken. Plik konfiguracyjny przechowuje dane uwierzytelniające w postaci jawnej, chyba że zastąpisz je odwołaniem do sekretu, który odczytuje wartość ze zmiennych środowiskowych lub pliku na dysku podczas startu. Niezależnie od metody, ten plik jest najbardziej wrażliwym elementem na serwerze: ustaw uprawnienia 600, przypisz właściciela opentag i nigdy nie umieszczaj go w repozytorium git. Szersza argumentacja znajduje się w przechowywanie sekretów poza agentami AI.

Sprawdź instalację przed wystawieniem czegokolwiek na zewnątrz.

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

opentag doctor weryfikuje dyspozytor, powiązania, checkouts oraz wykonawców. opentag status wyświetla konfigurację i stan środowiska uruchomieniowego; można ograniczyć zakres do pojedynczego uruchomienia, gdy istnieją już logi. Napraw wszystkie błędy zgłaszane przez doctor przed skierowaniem platformy na ten serwer.

Umieszczenie TLS przed usługami i otwarcie tylko dwóch ścieżek

nginx kończy połączenie TLS i przekazuje ruch tylko dla dwóch ścieżek. Wszystkie pozostałe zapytania zwracają błąd 404, dzięki czemu skaner wykrywający hosta nie uzyskuje informacji o usługach działających wewnątrz.

Należy utworzyć blok serwera dla portu 80 w /etc/nginx/sites-available/opentag z dwiema poniższymi lokalizacjami, a następnie pozwolić Certbot na dodanie konfiguracji TLS.

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 wyświetla syntax is ok oraz test is successful i stanowi jedyne zabezpieczenie przed błędem w składni, który mógłby spowodować wyłączenie witryny po przeładowaniu konfiguracji. Certbot w systemie Ubuntu 24.04 z nginx opisuje proces odnawiania certyfikatów oraz przyczyny niepowodzeń wyzwań ACME (automatic certificate management environment). Gotowy blok konfiguracyjny wygląda następująco.

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;
    }
}

= w location = /github/webhooks oznacza dokładne dopasowanie, a proxy_pass bez dodatkowych parametrów po porcie przekazuje oryginalny URI bez zmian. Usunięcie = spowodowałoby przekazywanie każdej ścieżki pod /github/webhooks/, co zwiększa powierzchnię ataku bardziej, niż jest to wymagane.

Firewall pozostaje w trybie ograniczonego dostępu.

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

Porty 3030, 3040 oraz 3050 nie są otwierane. Należy potwierdzić, że usługi są powiązane z interfejsem loopback, a nie ze wszystkimi dostępnymi interfejsami.

sudo ss -tlnp

Każda linia OpenTag powinna zawierać 127.0.0.1:3030 lub podobny zapis. Linia zawierająca 0.0.0.0:3050 oznacza, że usługa nasłuchuje na wszystkich interfejsach i jest chroniona wyłącznie przez ufw, co w przypadku błędu w konfiguracji firewalla może doprowadzić do wystawienia agenta na świat. Podstawy firewalla ufw wyjaśnia, jak działa domyślna polityka odrzucania połączeń.

Dwie kontrole potwierdzają poprawność konfiguracji bramy. curl -I https://opentag.example.com/ zwraca 404 z nginx, co potwierdza ważność certyfikatu i zamknięcie domyślnego bloku catch-all. Zapytanie do /slack/events lub /github/webhooks bez podpisu nigdy nie powinno zwrócić kodu 200.

Weryfikacja każdego podpisu ze względu na publiczny charakter adresu URL

Każdy może poznać adres URL ładunku (payload). Znajduje się on w ustawieniach repozytorium, historii przeglądarki lub na zrzucie ekranu wklejonym do zgłoszenia. Podpis jest jedynym elementem odróżniającym autentyczne dostarczenie z GitHub od żądania wpisanego ręcznie.

GitHub podpisuje każde dostarczenie za pomocą klucza webhook secret i przesyła wynik w nagłówku x-hub-signature-256. OpenTag weryfikuje ten nagłówek względem platforms.github.webhookSecret. Notatki dotyczące utwardzania zabezpieczeń projektu jasno określają zasadę: nie należy akceptować niepodpisanych zdarzeń źródłowych na /github/webhooks. Slack podpisuje każde żądanie za pomocą SLACK_SIGNING_SECRET i dołącza znacznik czasu, dzięki czemu przechwycona treść nie może zostać odtworzona (replay) kilka godzin później.

Pominięcie tego kroku wiąże się z poważnym ryzykiem. Niezweryfikowany punkt końcowy zaakceptuje ręcznie przygotowany ładunek issue_comment zawierający @opentag, a OpenTag uruchomi agenta programistycznego z Twoim tokenem, w Twoim katalogu roboczym, zgodnie z instrukcjami nieznajomej osoby. Odpowiedź zostanie wysłana do wątku wskazanego w fałszywym ładunku.

OpenTag dodaje dwie warstwy zabezpieczeń. Dostarczenia źródłowe są śledzone za pomocą identyfikatora delivery ID, więc ponowne dostarczenie tego samego zdarzenia nie inicjuje drugiego uruchomienia. Wywołania runnera akceptują klucze idempotentności, dzięki czemu powtórzenie żądania zwraca sukces bez dodawania kolejnego wpisu w audycie.

Limity szybkości (rate limits) są konfigurowalne i powinny być włączone. OPENTAG_RATE_LIMIT_WINDOW_MS oraz OPENTAG_RATE_LIMIT_MAX_REQUESTS ograniczają częstotliwość żądań, OPENTAG_MAX_REQUEST_BODY_BYTES ogranicza rozmiar treści, a zbyt duży ładunek jest odrzucany z błędem 413 request_body_too_large. OPENTAG_RATE_LIMIT_DISABLED=true służy wyłącznie do lokalnego programowania i nie powinno być używane na publicznie dostępnym serwerze. Kolejna zasada z tych samych notatek: publiczny adres URL przekaźnika musi korzystać z HTTPS, a CLI zezwala na użycie zwykłego HTTP wyłącznie dla localhost.

Jakich zakresów uprawnień (scopes) faktycznie potrzebuje bot?

W serwisie GitHub narzędzie OpenTag korzysta z precyzyjnie określonego tokena dostępu osobistego (fine-grained personal access token), a nie z aplikacji GitHub App. Dokumentacja wskazuje, że ścieżka z wykorzystaniem aplikacji jest planowana i nie stanowi obecnie domyślnej konfiguracji CLI, co niesie za sobą konsekwencję często pomijaną przez użytkowników: bot zamieszcza komentarze jako osoba, która utworzyła token. Należy go utworzyć na koncie, którego nazwa ma widnieć w każdej odpowiedzi dotyczącej triażu zgłoszeń.

Zakres uprawnień należy ograniczyć zgodnie z instrukcją konfiguracji. Należy wybrać opcję Only select repositories i wskazać jeden z nich. Następnie należy przyznać uprawnienia Issues: Read and write oraz Pull requests: Read and write. Jest to wystarczające, aby odczytać wzmiankę i odpowiedzieć w wątku.

Warto zwrócić uwagę na to, czego brakuje: uprawnień do zapisu kodu. OpenTag nie wypycha (push) gałęzi, chyba że zmienna preparePullRequestBranch jest ustawiona na true, a osobna zmienna githubApplyToken istnieje po to, aby token służący do zapisu kodu nie był tym samym, który służy do zamieszczania komentarzy. Należy je rozdzielić i nie aktywować tokena z uprawnieniami do zapisu, dopóki ścieżka odczytu i komentowania nie będzie działać poprawnie przez kilka tygodni.

Konfiguracją, której należy unikać, jest token z uprawnieniami Contents: Read and write dla All repositories. Każda osoba mogąca komentować w którymkolwiek z tych repozytoriów może w ten sposób sterować agentem posiadającym uprawnienia do zatwierdzania zmian (commit), a ścieżka audytu wykaże, że dokonał tego właściciel tokena. Zakres uprawnień należy rozszerzać o kolejne repozytoria dopiero po tym, jak agent potwierdzi swoją niezawodność.

W przypadku Slacka zakresy uprawnień bota to app_mentions:read, chat:write, reactions:write oraz channels:history. Kanały prywatne wymagają dodatkowo groups:history oraz subskrypcji zdarzenia message.groups. Tryb Socket Mode wymaga tokena na poziomie aplikacji z uprawnieniem connections:write, czyli takiego, który zaczyna się od xapp-. Uprawnienie channels:history umożliwia odczyt historii wiadomości na kanałach publicznych, do których bot został dodany, dlatego należy dodawać bota tylko do wybranych kanałów, zamiast do wszystkich.

Obsługa zgłoszenia od początku do końca

Najpierw należy skonfigurować webhook. W repozytorium otwórz Settings, następnie Webhooks i wybierz Add webhook. Adres URL ładunku (payload URL) to https://opentag.example.com/github/webhooks, typ zawartości to application/json, a klucz tajny (secret) to ciąg wygenerowany podczas konfiguracji. Zasubskrybuj wyłącznie Issue comments oraz Pull request review comments.

GitHub wyśle zdarzenie typu ping natychmiast po zapisaniu konfiguracji. Otwórz Recent Deliveries i sprawdź, czy żądanie dotarło do serwera. Kod 502 oznacza, że nginx nie mógł połączyć się z usługą nasłuchującą; jest to problem lokalny, a nie po stronie GitHub.

Teraz przetestuj działanie. Otwórz zgłoszenie opisujące błąd i dodaj komentarz:

@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.

Oto oczekiwana kolejność zdarzeń. W sekcji Recent Deliveries pojawi się dostarczenie issue_comment z odpowiedzią 2xx. Dyspozytor zarejestruje uruchomienie. Runner przejmie zadanie i rozpocznie wysyłanie sygnałów heartbeat. Executor pobierze kod (checkout) i rozpocznie pracę. Odpowiedź pojawi się jako komentarz w tym samym wątku zgłoszenia. sudo -iu opentag opentag status pokazuje uruchomienie w trakcie jego trwania, co pozwala na monitorowanie postępów zamiast zgadywania.

Przed pierwszym rzeczywistym uruchomieniem ustaw approvalMode na ask. W trybie ask proces zatrzymuje się i czeka na interwencję użytkownika przed wykonaniem jakiejkolwiek operacji zmieniającej stan. Dostępne są również tryby auto oraz autonomous, które warto rozważyć w późniejszym czasie, gdy w repozytorium zgromadzisz już miesięczną historię transkrypcji.

Po stronie Slack to samo uruchomienie rozpoczyna się od /bind owner/repo na kanale, a następnie wzmianki. Bot odpowiada również na /help, /status, /doctor, /stop oraz /unbind confirm. Ogranicz możliwość zmiany powiązań za pomocą OPENTAG_SLACK_BINDING_ADMIN_USER_IDS, podając listę identyfikatorów użytkowników Slack oddzielonych przecinkami, ponieważ powiązanie to mapowanie publicznego kanału na katalog roboczy (checkout) na Twoim serwerze.

Triage jest dobrym pierwszym krokiem, ponieważ agent jedynie odczytuje dane bez ich modyfikacji, a poprawność odpowiedzi jest łatwa do oceny. Kolejnym etapem jest Review, gdzie agent komentuje różnice w kodzie (diff) zamiast zgłoszenia: własny agent do przeglądu pull requestów wykorzystuje tę samą architekturę skierowaną na pull requesty. Jeśli chcesz, aby agent uzyskiwał dostęp do Twoich systemów podczas pracy, służą do tego serwery MCP na VPS. Wyszukiwanie w sieci to kolejna funkcja, o którą często pyta triage, a podłączenie agenta do własnej instancji SearXNG pozwala zachować kontrolę nad tymi zapytaniami na własnym sprzęcie, kosztem dodania kolejnego kanału, przez który tekst zewnętrzny trafia do agenta.

Co się dzieje, gdy agent popełni błąd na oczach wszystkich?

Popełni błąd. Pytanie brzmi, jaki będzie tego koszt.

Błędna odpowiedź w publicznym zgłoszeniu to komentarz pod nazwą rozpoznawalną dla zespołu, a GitHub wysyła go w powiadomieniu e-mail do wszystkich subskrybentów w momencie publikacji. Usunięcie komentarza nie wycofa wiadomości e-mail. To samo dotyczy powiadomień w Slack. Należy zakładać, że odpowiedź będzie błędna publicznie, zamiast liczyć na to, że będzie poprawna w prywatnym obiegu.

Cztery opcje ograniczają zakres szkód i mają większe znaczenie niż jakikolwiek prompt.

• Uruchomienie w trybie ask sprawia, że agent proponuje rozwiązanie, człowiek je zatwierdza, a koszt błędnego planu to jedno kliknięcie.
• Pozostawienie preparePullRequestBranch na domyślnej wartości false sprawia, że najgorszym skutkiem nieudanego uruchomienia jest błędny komentarz, a nie błędna gałąź (branch).
• Powiązanie jednego repozytorium z jednym kanałem na początek. Runner odrzuca każde uruchomienie, którego cel projektu znajduje się poza lokalną listą dozwolonych (allowlist), więc niepowiązane repozytorium nie może wymusić działania agenta.
• Rozdzielenie tokena do komentowania od tokena do wprowadzania zmian (apply token), dzięki czemu cofnięcie uprawnień do zapisu nie powoduje wyłączenia obsługi zgłoszeń (triage).

Slack posiada komendę /stop dla uruchomienia, które przebiega w niewłaściwy sposób. Każde uruchomienie pozostawia również rekord audytu zawierający wzmiankę, która je zainicjowała, oraz opis działań agenta; jest to materiał, który analizuje się później, aby ustalić przyczynę błędu.

Aspekt społeczny jest równie ważny co konfiguracja. Umieść bota na kanale, gdzie ludzie spodziewają się maszyny i wiedzą, że może ona popełnić błąd. Pewna siebie, błędna odpowiedź na kanale z czterdziestoma osobami, które zakładają, że treść została zweryfikowana przez człowieka, kosztuje więcej niż oszczędności wynikające z automatyzacji triage'u. W opisie kanału zamieść informację, kto odpowiada za bota i kto sprawdza jego dane wyjściowe.

Kopie zapasowe, aktualizacje i przypinanie wersji

Wszystkie dane znajdują się w dwóch ścieżkach: /home/opentag/.config/opentag/config.json oraz /home/opentag/.local/state/opentag. Pierwsza zawiera dane uwierzytelniające, druga historię uruchomień oraz plik bazy danych. Należy wykonać kopię zapasową obu lokalizacji z uprawnieniami 600 i przechowywać ją poza serwerem. Utrata tych plików oznacza konieczność ponownego wygenerowania tokenów i powiązań, a nie odbudowę całego serwera.

Aktualizacje polegają na zmianie wersji i restarcie usługi.

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

Zaleca się przypinanie wersji zamiast śledzenia @latest. Oprogramowanie to uruchamia agenta programistycznego wewnątrz repozytorium przy użyciu aktywnego tokena, więc wydanie opublikowane w nocy stanowi niezweryfikowaną zmianę w środowisku. Polityka bezpieczeństwa nie przewiduje backportów, a poprawki trafiają wyłącznie do najnowszego wydania. Przypinanie wersji oznacza zatem świadome zapoznanie się z dziennikiem zmian przed aktualizacją. Nie oznacza to pozostawania przy wersji v0.9.0 na stałe. Historia do lipca 2026 roku wskazuje na kilka wydań miesięcznie, co stanowi wystarczający powód, aby przed każdą aktualizacją przeczytać informacje o wydaniu.

FAQ

Czy do uruchomienia OpenTag potrzebny jest VPS, czy wystarczy laptop?

Laptop wystarczy wyłącznie w przypadku Slacka, ponieważ Socket Mode otwiera wychodzące połączenie WebSocket i nie wymaga portów przychodzących. W przypadku GitHub sytuacja wygląda inaczej. Webhooki repozytorium przesyłają dane za pomocą przychodzących żądań HTTP na zarejestrowany adres URL, dlatego musi on być stały i dostępny przez całą dobę. Adres hosta tunelu z darmowego konta zmienia się przy każdym restarcie, przez co GitHub wysyła dane na nieaktualny adres, co skutkuje błędami w zakładce Recent Deliveries repozytorium oraz brakiem aktywności w wątku. VPS ze stałą nazwą DNS i certyfikatem eliminuje oba te problemy.

Jakich uprawnień w GitHub wymaga OpenTag?

Wymagany jest token typu fine-grained personal access token ograniczony do Only select repositories, z uprawnieniami Issues: Read and write oraz Pull requests: Read and write. Pozwala to na odczytywanie wzmianek i odpowiadanie w wątkach. Uprawnienia do zapisu kodu nie są potrzebne, chyba że ustawiono preparePullRequestBranch na true, co pozwala OpenTag na wypychanie branchy. Istnieje również osobna opcja githubApplyToken, dzięki której token do zapisu kodu jest odseparowany od tokena do komentowania. Należy unikać tokenów z uprawnieniami do zapisu treści dla wszystkich repozytoriów, ponieważ każda osoba mogąca komentować w tych repozytoriach mogłaby sterować agentem posiadającym uprawnienia do commitowania.

Jak zatrzymać błędnie działające zadanie?

Slack posiada komendę /stop przeznaczoną właśnie do tego celu. Na serwerze polecenie opentag status wyświetla aktualnie uruchomione procesy, a opentag service stop zatrzymuje demona, co kończy całą potokową realizację zadań, a nie tylko pojedyncze uruchomienie. Aby uniknąć konieczności korzystania z tych metod, należy ustawić approvalMode na ask, co spowoduje wstrzymanie zadań do momentu zatwierdzenia przez użytkownika przed wprowadzeniem jakichkolwiek zmian. Warto również pozostawić preparePullRequestBranch ustawione na false, aby nieudane zadanie skutkowało dodaniem komentarza zamiast utworzeniem brancha.

Dlaczego mój webhook zwraca błąd 502, podczas gdy wątek pozostaje cichy?

Błąd 502 pochodzi z nginx, a nie z OpenTag, i oznacza, że proxy nie może połączyć się z usługą nasłuchującą. Polecenie /var/log/nginx/error.log wyświetli connect() failed (111: Connection refused) while connecting to upstream. Usługa nasłuchująca jest albo zatrzymana, albo działa na innym porcie niż zdefiniowano w linii proxy_pass. Należy wykonać sudo ss -tlnp i potwierdzić, że procesy nasłuchują na portach 127.0.0.1:3050 dla GitHub oraz 127.0.0.1:3040 dla Slack, a następnie uruchomić opentag doctor w celu weryfikacji powiązań i wykonawców.