Paano i-self host ang OpenTag para sa coding agent

Ano ang ginagawa ng OpenTag kapag nag-mention ka ng agent

Ginagawang coding agent ng OpenTag ang isang @mention sa Slack thread o GitHub issue na tumatakbo sa sarili mong machine. May magko-comment ng @opentag investigate this sa isang issue. Ang listener ay tatanggap ng platform event, iche-check ang signature nito, itatugma ang mention sa nakatalagang project, magpapatakbo ng coding agent laban sa isang local checkout, at ipo-post ang resulta pabalik sa parehong thread.

Ang project ay may MIT license at matatagpuan sa amplifthq/opentag. Simula noong August 2026, ang pinakabagong tagged release ay v0.9.0, na inilabas noong 28 July 2026, at ito ay ipinamamahagi bilang isang npm package. Walang opisyal na container image, kaya ang bersyon ng npm ang dapat mong i-pin. Ang bawat command sa ibaba ay nag-pi-pin nito.

Nagiging VPS project ito sa halip na laptop project dahil sa aspeto ng GitHub. Nagpapadala ang GitHub ng mga repository event sa pamamagitan ng paggawa ng HTTP request sa isang URL na ire-register mo nang isang beses, kaya kailangang manatiling accessible ang URL na iyon sa parehong address kahit bukas.

Ang apat na gumagalaw na bahagi

Ang listener ang tumatanggap ng mga platform event, at bawat platform ay may kanya-kanya nito. Ang GitHub listener ay isang HTTP endpoint sa port 3050 sa path na /github/webhooks. Ang Slack Events API listener naman ay nasa port 3040 sa /slack/events. Maaari ring tumakbo ang Slack sa Socket Mode, kung saan nagbubukas ang app ng outbound WebSocket at hindi na nangangailangan ng anumang inbound port.

Ang dispatcher ang nagsisilbing coordinator. Nakikinig ito sa port 3030 bilang default, pinapanatili ang run state sa isang local database file na itinakda ng OPENTAG_DATABASE_PATH, at nagtatala ng audit trail para sa bawat run. Walang anumang bagay sa labas ng box ang dapat makakaabot sa port na ito.

Ang runner ang lokal na daemon. Nag-po-poll ito para sa trabaho, nag-ke-claim ng run, humahawak ng lease dito, at nagpapadala ng heartbeat kada 15 segundo bilang default habang buhay ang run. Tinatanggihan nito ang anumang na-claim na run kung ang project target ay nawawala o wala sa allowlist sa sarili nitong config; ito ang check na pumipigil sa isang GitHub event na ituro ang iyong agent sa isang repository na hindi mo naman binigkis (bind).

Ang executor ang mismong coding agent. Inilulunsad ito ng OpenTag sa pamamagitan ng ACP (agent client protocol), isang JSON-RPC protocol na ginagamitan ng standard input at output, kaya tumatakbo ang agent bilang child process sa loob ng working directory na ibinibigay ng OpenTag. Ang mga built-in na pangalan ay kinabibilangan ng echo, codex, claude-code, cursor, opencode, hermes at openclaw. Magsimula sa echo, ang executor na kasama sa example config, dahil pinapatunayan nito na gumagana ang buong path bago pa man hawakan ng isang model ang iyong code.

Hindi nagbabago ang pagkakasunod-sunod: platform event, signature check, run record, claim, agent, reply sa thread.

Bakit hindi sapat ang laptop at tunnel

Sinasabi ng setup guide ng GitHub na patakbuhin ang ngrok http 3050 at i-paste ang tunnel host sa webhook ng repository. Gumagana ito sa unang sampung minuto. Ang libreng tunnel host ay nagbabago sa tuwing mag-re-restart ang proseso, at nawawala ito kapag natulog ang laptop. Pinapanatili ng GitHub ang lumang payload URL at patuloy itong sinusubukan, kaya napupuno ng mga error ang tab na Recent Deliveries sa webhook settings habang nananatiling tahimik ang thread. Walang nakakapansin sa loob ng isang linggo, dahil ang webhook na walang ginagawa ay mukhang bot na hindi naman binanggit ng kahit sino.

Inaayos ng VPS ang dalawang bagay na sumisira sa setup. Hindi nagbabago ang DNS name, kaya ang payload URL na i-paste mo nang isang beses ay mananatiling tama. Hindi natutulog ang machine, kaya ang comment sa 02:00 ay makakatanggap ng sagot. I-set up nang maayos ang box: ang unang sampung minuto sa bagong VPS ay sumasaklaw sa login user at firewall na ipinapalagay ng gabay na ito.

Ang Slack ang exception. Sa Socket Mode, kumokonekta ito palabas at hindi nangangailangan ng public URL, kaya ang deployment na Slack lang ang gamit ay maaaring manatiling closed. Walang katumbas na ganito ang GitHub. Ang mga repository webhook ay inbound HTTP, na nangangahulugang kailangan ng public endpoint, TLS (transport layer security), at signature check.

Pag-host ng OpenTag sa Ubuntu mula sa isang pinned release

Ang OpenTag v0.9.0 ay nangangailangan ng Node.js 22 o mas bago. Ang Ubuntu 24.04 ay may Node 18 sa sarili nitong repository, kaya mag-install mula sa 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

Dapat mag-print ang node -v ng v22 o mas mataas. Sa Node 20, ang install ay naglalabas ng EBADENGINE warning at maaaring mag-fail ang CLI pagka-start nito.

Bigyan ang serbisyo ng sarili nitong account. Tumatakbo ang agent gamit ang permissions ng user na ito, kaya hindi ito dapat ang iyong login at hindi rin ito dapat ang root. Ang Least privilege users on a VPS ay nagpapaliwanag kung bakit sulit ang dagdag na hakbang na ito para sa separation.

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

Dapat mag-print ang command -v opentag ng path gaya ng /usr/bin/opentag. Mahalaga ang linger setting sa Linux: ang OpenTag ay nag-i-install ng background service nito sa pamamagitan ng systemd, at ang user service na walang lingering ay humihinto sa sandaling magsara ang iyong SSH session.

Patakbuhin ang setup bilang user na iyon.

sudo -iu opentag opentag setup

Anim na bagay ang tinatanong ng setup: ang CLI language, ang local listening address, ang coding agent, ang local project na pagtatrabahuhan, ang platform credentials na ise-save, at kung paano ito patatakbuhin. Panatilihin ang listening address sa 127.0.0.1, dahil ang nginx ang nag-te-terminate ng TLS at nagpapasa nito, kaya hindi kailangang maabot ang mga listener mula sa labas. Para sa GitHub, tinatanong din nito ang repository sa format na owner/repo, kung maaari itong magbukas ng pull requests, ang webhook port (3050 bilang default), at ang token. Piliin ang background service mode sa dulo. Kung mayroon ka nang config at gusto mong ma-install ang serbisyo nang walang prompts, ginagawa ito ng opentag setup --service.

Ang config ay napupunta sa /home/opentag/.config/opentag/config.json at ang runtime state sa /home/opentag/.local/state/opentag. Sulit na i-check nang manual ang mga key na ito matapos isulat ng setup ang file.

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

Mas mainam ang runnerToken, ang runner-scoped bearer token, kaysa sa mas lumang shared pairingToken. Ang config file ay nagtatago ng credentials sa plain text maliban kung papalitan mo ang mga ito ng secret reference, na nagbabasa ng value mula sa environment o mula sa file sa disk sa oras ng startup. Alinman sa dalawa, ang file na ito ang pinaka-sensitive na bagay sa box: mode 600, pagmamay-ari ng opentag, at hindi dapat ilagay sa loob ng git repository. Ang mas malawak na argumento ay nasa keeping secrets out of AI agents.

I-check ang install bago mag-expose ng kahit ano.

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

Ang opentag doctor ay nag-che-check ng dispatcher, bindings, checkouts, at executors. Ang opentag status ay nagpi-print ng config at runtime state, at maaari itong i-scope sa isang run kapag mayroon nang mga run. Ayusin ang lahat ng ini-report ng doctor bago mo ituro ang isang platform sa box na ito.

Ilagay ang TLS sa harap at magbukas lamang ng dalawang path

Ang nginx ang nagtatapos ng TLS at nagpapasa ng eksaktong dalawang path. Lahat ng iba ay magbabalik ng 404, kaya walang matututunan ang isang scanner tungkol sa kung ano ang tumatakbo sa likod nito.

Sumulat ng plain port 80 server block sa /etc/nginx/sites-available/opentag kasama ang dalawang location sa ibaba, pagkatapos ay hayaan ang Certbot na idagdag ang TLS half.

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

Ang nginx -t ay nagpi-print ng syntax is ok at test is successful, at ito lamang ang pumipigil sa isang typo na maging sanhi ng reload na magpapabagsak sa site. Ang Certbot sa Ubuntu 24.04 na may nginx ay sumasaklaw sa renewal at sa mga paraan kung paano nabibigo ang isang ACME (automatic certificate management environment) challenge. Ganito ang hitsura ng natapos na block.

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

Ang = sa location = /github/webhooks ay isang exact match, at ang proxy_pass na walang kasunod na anuman pagkatapos ng port ay nagpapasa ng orihinal na URI nang walang pagbabago. Alisin ang = at bawat path sa ilalim ng /github/webhooks/ ay ipapasa rin, na mas malawak na surface kaysa sa kailangan ng listener.

Mananatiling limitado ang firewall.

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

Ang mga port 3030, 3040, at 3050 ay hindi kailanman bubuksan. Kumpirmahin na ang mga ito ay naka-bind sa loopback sa halip na sa bawat interface.

sudo ss -tlnp

Ang bawat OpenTag line ay dapat magbasa ng 127.0.0.1:3030 o katulad nito. Ang isang linya na nagbabasa ng 0.0.0.0:3050 ay nangangahulugan na ang listener ay inaalok ang sarili nito sa buong internet at ang ufw lamang ang pumipigil dito, na isang pagkakamali sa firewall ang layo mula sa isang open agent trigger. Ang mga pangunahing kaalaman sa ufw firewall ay nagpapaliwanag kung ano talaga ang ginagawa ng default deny na iyon.

Dalawang pagsusuri ang nagpapatunay sa front door. Ang curl -I https://opentag.example.com/ ay nagbabalik ng 404 mula sa nginx, na nagpapakita na ang certificate ay valid at ang catch-all ay sarado. Ang isang request sa /slack/events o /github/webhooks na walang signature ay hindi dapat magbalik ng 200.

I-verify ang bawat signature dahil public ang URL

Kahit sino ay makakahanap ng payload URL. Nakalagay ito sa settings ng iyong repository, sa browser history, o sa screenshot na ipinasa sa isang ticket. Ang signature lamang ang naghihiwalay sa totoong GitHub delivery mula sa request na tinipa lang ng kung sino.

Nilalagdaan ng GitHub ang bawat delivery gamit ang webhook secret at ipinapadala ang resulta sa header na x-hub-signature-256. I-verify ng OpenTag ang header na iyon laban sa platforms.github.webhookSecret. Direkta ang nakasaad na panuntunan sa hardening notes ng proyekto: huwag tumanggap ng unsigned source events sa /github/webhooks. Nilalagdaan ng Slack ang bawat request gamit ang SLACK_SIGNING_SECRET at nagsasama ng timestamp, kaya hindi maaaring i-replay ang isang nakuhang body pagkalipas ng ilang oras.

Ang paglaktaw dito ay hindi maliit na panganib. Ang isang unverified endpoint ay tatanggap ng hand-written na issue_comment payload na naglalaman ng @opentag, at pagkatapos ay magpapatakbo ang OpenTag ng coding agent, gamit ang iyong token, sa iyong checkout, base sa mga instruksyon ng isang estranghero. Ang sagot ay mapupunta sa kahit anong thread na tinukoy ng pekeng payload.

Nagdaragdag ang OpenTag ng dalawang layer sa itaas nito. Ang mga source delivery ay sinusubaybayan gamit ang delivery ID, kaya ang muling pag-deliver ng parehong event ay hindi magsisimula ng pangalawang run. Ang mga runner call ay tumatanggap ng idempotency keys, kaya ang pag-replay ng isa ay magbabalik ng success nang hindi nagdaragdag ng isa pang audit event.

Ang rate limits ay configurable at dapat naka-on. Nililimitahan ng OPENTAG_RATE_LIMIT_WINDOW_MS at OPENTAG_RATE_LIMIT_MAX_REQUESTS ang request rate, nililimitahan ng OPENTAG_MAX_REQUEST_BODY_BYTES ang body, at ang oversized payload ay nare-reject gamit ang 413 request_body_too_large. Ang OPENTAG_RATE_LIMIT_DISABLED=true ay para sa local development lamang, at wala itong lugar sa isang public box. Isa pang panuntunan mula sa parehong notes: ang isang public relay URL ay dapat gumamit ng HTTPS, at ang CLI ay pinapayagan lamang ang plain HTTP para sa localhost.

Anong mga token scope ang kailangan talaga ng bot?

Sa GitHub, gumagamit ang OpenTag ng fine-grained personal access token sa halip na GitHub App. Sinasabi ng docs na planado pa lang ang App path at hindi ito ang default na setup ng CLI sa ngayon, at may epekto ito na madalas makaligtaan ng mga tao: ang bot ay nagko-comment sa pangalan ng taong gumawa ng token. Gawin ito sa ilalim ng account na handa mong makitang nakapangalan sa bawat triage reply.

Limitahan ang scope nito ayon sa setup guide. Piliin ang Only select repositories at pumili ng isa. Ibigay ang Issues: Read and write at Pull requests: Read and write. Sapat na ito para makabasa ng mention at makasagot sa thread.

Pansinin ang kulang: write access sa code. Hindi nagpu-push ng branches ang OpenTag maliban kung ang preparePullRequestBranch ay naka-set sa true, at may hiwalay na githubApplyToken para ang token na nagsusulat ng code ay hindi ang token na nagsusulat ng comments. Panatilihin silang magkahiwalay, at huwag munang gamitin ang write token hangga't hindi pa tumatakbo nang ilang linggo ang read-and-comment path.

Ang configuration na dapat iwasan ay ang token na may Contents: Read and write sa All repositories. Ang sinumang makakapag-comment sa alinman sa mga repository na iyon ay maaari nang mag-utos sa agent na may commit rights, at sa audit trail, ang may-ari ng token ang lalabas na gumawa nito. Palawakin ang scope nang paisa-isang repository lang, matapos itong mapatunayan ng agent.

Sa Slack, ang mga bot scope ay app_mentions:read, chat:write, reactions:write at channels:history. Ang mga private channel ay nangangailangan din ng groups:history at subscription sa message.groups event. Ang Socket Mode ay nangangailangan ng app-level token na may connections:write, ang nagsisimula sa xapp-. Binabasa ng channels:history ang message history sa mga public channel kung saan idinagdag ang bot, kaya idagdag lang ang bot sa mga channel kung saan ito kailangan sa halip na sa lahat.

I-trace ang isang issue mula simula hanggang dulo

Ang webhook ang unang hakbang. Sa repository, buksan ang Settings, pagkatapos ay Webhooks, at i-click ang Add webhook. Ang payload URL ay https://opentag.example.com/github/webhooks, ang content type ay application/json, at ang secret ay ang nabuo noong setup. Mag-subscribe lamang sa Issue comments at Pull request review comments, at wala nang iba.

Magpapadala ang GitHub ng ping delivery agad pagka-save mo. Buksan ang Recent Deliveries at tingnan kung nakarating ang request sa server. Ang 502 error ay nangangahulugang hindi maabot ng nginx ang listener; ito ay lokal na problema at hindi sa GitHub.

Ngayon, gamitin ito. Magbukas ng issue na naglalarawan ng bug at mag-comment ng:

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

Narito ang dapat mangyari, ayon sa pagkakasunod-sunod. Itatala ng Recent Deliveries ang issue_comment delivery na may 2xx response. Magtatala ang dispatcher ng isang run. I-a-claim ito ng runner at magsisimulang mag-heartbeat. Bubuksan ng executor ang checkout at magtatrabaho. Darating ang sagot bilang comment sa parehong issue thread. Ipinapakita ng sudo -iu opentag opentag status ang run habang ito ay kasalukuyang tumatakbo, kaya maaari mo itong bantayan sa halip na manghula.

I-set ang approvalMode sa ask bago ang unang totoong run. Sa ask mode, hihinto ang run at maghihintay ng tao bago gumawa ng anumang pagbabago sa state. Umiiral din ang auto at autonomous modes, at mainam itong gamitin sa hinaharap, kapag nakapagbasa ka na ng isang buwang dami ng transcripts sa repository.

Sa panig ng Slack, magsisimula ang parehong run gamit ang /bind owner/repo sa channel, na susundan ng isang mention. Sasagot din ang bot ng /help, /status, /doctor, /stop at /unbind confirm. Limitahan ang mga taong maaaring magbago ng bindings gamit ang OPENTAG_SLACK_BINDING_ADMIN_USER_IDS, isang listahan ng mga Slack user ID na pinaghihiwalay ng kuwit, dahil ang binding ay ang mapping mula sa isang public channel patungo sa isang checkout sa iyong server.

Ang triage ang magandang unang ruta dahil nagbabasa lang ito at hindi nagsusulat, at madaling i-grade ang sagot. Ang review ang susunod na antas, kung saan nagko-comment ang agent sa isang diff sa halip na sa issue: ang self-hosted pull request review agent ay gumagamit ng parehong arkitektura na nakatutok sa mga pull request. Kung gusto mong maabot ng agent ang sarili mong mga system habang nagtatrabaho ito, iyan ang trabaho ng MCP servers sa isang VPS. Ang web search ang isa pang kakayahan na patuloy na hinihingi ng triage, at ang pag-wire ng agent sa sarili mong SearXNG instance ay nagpapanatili ng mga lookup na iyon sa hardware na ikaw ang nagpapatakbo, kapalit ng isa pang channel kung saan maaaring makarating ang text ng ibang tao sa agent.

Ano ang mangyayari kapag nagkamali ang agent sa harap ng lahat?

Magkakamali ito. Ang tanong ay kung ano ang kapalit nito.

Ang maling sagot sa isang pampublikong isyu ay isang comment sa ilalim ng pangalang kilala ng iyong team, at ipapadala ito ng GitHub sa lahat ng naka-subscribe sa sandaling ma-post ito. Hindi mababawi ng pag-delete sa comment ang email. Ganoon din ang mangyayari sa Slack notification. Magplano para sa posibilidad na magkamali ang sagot sa publiko sa halip na umasa lang na tama ito sa pribado.

Apat na opsyon ang naglilimita sa pinsala, at mas mahalaga ang mga ito kaysa sa anumang prompt na isusulat mo.

• Patakbuhin sa ask mode, para ang agent ang magmungkahi, ang tao ang mag-a-approve, at ang maling plano ay isang click lang ang katumbas na abala.
• Iwanan ang preparePullRequestBranch sa default nitong false, para ang pinakamalalang resulta ng isang maling run ay isang maling comment sa halip na maling branch.
• Mag-bind ng isang repository at isang channel sa simula. Tinatanggihan ng runner ang anumang run kung ang target na project ay wala sa local allowlist nito, kaya hindi maaaring hilahin ng agent ang sarili nito sa isang unbound na repository.
• Panatilihing hiwalay ang commenting token sa anumang apply token, para hindi madamay ang triage kapag binawi ang write access.

Ang Slack ay may /stop command para sa isang run na nagkakamali ang direksyon. Ang bawat run ay nag-iiwan din ng audit record na naglalaman ng mention na nagpasimula nito at kung ano ang ginawa ng agent, na siyang binabasa mo pagkatapos upang malaman kung saan ito nagkamali.

Kasinghalaga ng config ang aspetong panlipunan. Ilagay ang bot sa isang channel kung saan inaasahan ng mga tao ang isang machine at alam nilang maaari itong magkamali. Ang isang tiwalang maling sagot sa isang channel na may apatnapung tao na nag-aakalang tao ang nag-review nito ay mas malaki ang gastos kaysa sa natipid na oras sa triage. Isulat sa description ng channel kung sino ang nagmamay-ari ng bot at kung sino ang nag-che-check ng output nito.

Backups, upgrades, at ang pin

Dalawang path ang naglalaman ng lahat: /home/opentag/.config/opentag/config.json at /home/opentag/.local/state/opentag. Ang una ay naglalaman ng iyong mga credential, habang ang pangalawa ay naglalaman ng run history at ang database file. I-back up ang pareho gamit ang mode 600, at itago ang mga ito sa labas ng server. Ang pagkawala ng mga ito ay nangangahulugan ng muling paggawa ng mga token at binding, hindi ang pagbuo muli ng server.

Ang mga upgrade ay binubuo ng version bump at restart.

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

I-pin ang version sa halip na i-track ang @latest. Ang software na ito ay nagpapatakbo ng coding agent laban sa iyong repository gamit ang live token, kaya ang release na inilabas sa gabi ay isang hindi na-review na pagbabago para dito. Ang security policy ay walang backport, at ang mga fix ay dumarating lamang sa pinakabagong release, kaya ang pag-pin ay nangangahulugan na binabasa mo ang changelog at sinasadya ang pag-update. Hindi ito nangangahulugan ng pananatili sa v0.9.0 habambuhay. Ang history hanggang July 2026 ay nagpapakita ng ilang release kada buwan, na isang magandang dahilan para basahin ang release notes bago ang bawat bump.

FAQ

Kailangan ko ba ng VPS para patakbuhin ang OpenTag, o sapat na ang laptop?

Sapat na ang laptop para sa Slack lang, dahil ang Socket Mode ay nagbubukas ng outbound WebSocket at hindi nangangailangan ng inbound port. Iba ang GitHub. Ang mga repository webhook ay nagpapadala sa pamamagitan ng inbound HTTP sa isang URL na ire-register mo nang isang beses, kaya dapat manatiling pareho ang address at dapat itong sumasagot kahit tulog ka. Ang tunnel host mula sa isang libreng account ay nagbabago sa bawat restart, at patuloy na magpapadala ang GitHub sa luma, na lalabas bilang mga failed entry sa tab na Recent Deliveries ng repository at bilang katahimikan sa thread. Ang isang VPS na may fixed DNS name at certificate ang nagtatanggal sa parehong problema.

Anong mga GitHub permission ang kailangan ng OpenTag?

Isang fine-grained personal access token na limitado sa Only select repositories, na may Issues: Read and write at Pull requests: Read and write. Sapat na iyon para makabasa ng mention at makasagot sa thread. Hindi kailangan ng write access sa code maliban kung i-set mo ang preparePullRequestBranch sa true para mag-push ng branches ang OpenTag, at may hiwalay na githubApplyToken para manatiling nakahiwalay ang token para sa pagsusulat ng code sa token para sa pag-comment. Iwasan ang all-repositories token na may contents write, dahil ang sinumang makakapag-comment sa alinman sa mga repository na iyon ay maaaring mag-manipula ng agent na may kakayahang mag-commit.

Paano ko ititigil ang isang run na nagkakamali?

Ang Slack ay may /stop command para mismo rito. Sa server, ipinapakita ng opentag status kung ano ang tumatakbo, at ang opentag service stop ang nagpapatigil sa daemon, na nagtatapos sa buong pipeline sa halip na sa isang run lang. Para maiwasan ang paggamit ng alinman sa mga ito, i-set ang approvalMode sa ask para huminto ang mga run at maghintay ng tao bago sila magbago ng anuman, at panatilihin ang preparePullRequestBranch sa false para ang isang maling run ay mag-produce na lang ng comment sa halip na branch.

Bakit 502 ang ibinabalik ng webhook ko habang nananatiling tahimik ang thread?

Ang 502 ay galing sa nginx, hindi sa OpenTag, at ibig sabihin nito ay hindi maabot ng proxy ang listener. Ipakikita ng /var/log/nginx/error.log ang connect() failed (111: Connection refused) while connecting to upstream. Maaaring huminto ang listener, o kaya ay nasa ibang port ito kaysa sa nakasaad sa linyang proxy_pass. Patakbuhin ang sudo ss -tlnp at kumpirmahin kung may nakikinig sa 127.0.0.1:3050 para sa GitHub at 127.0.0.1:3040 para sa Slack, pagkatapos ay patakbuhin ang opentag doctor para sa mga binding at executor.