Jinsi ya kuendesha OpenTag kwenye VPS yako

Kile ambacho OpenTag hufanya unapotaja wakala

OpenTag hubadilisha @mention kwenye thread ya Slack au issue ya GitHub kuwa uendeshaji wa wakala wa usimbaji (coding agent) kwenye mashine unayomiliki. Mtu akitoa maoni @opentag investigate this kwenye issue, msikilizaji (listener) hupokea tukio la jukwaa, hukagua sahihi yake, hulinganisha tajio hilo na mradi uliounganishwa, huanzisha wakala wa usimbaji dhidi ya faili zilizopo kwenye mashine yako, na kuchapisha matokeo kwenye thread hiyo hiyo.

Mradi huu una leseni ya MIT na unapatikana katika amplifthq/opentag. Kufikia Agosti 2026, toleo jipya zaidi lililowekewa tag ni v0.9.0, lililochapishwa tarehe 28 Julai 2026, na linasambazwa kama npm package. Hakuna image rasmi ya container, kwa hivyo kitu unachopaswa ku-pin ni toleo la npm. Kila amri iliyo hapa chini inali-pin toleo hilo.

Huu unakuwa mradi wa VPS badala ya mradi wa kompyuta ya mkononi kwa sababu ya upande wa GitHub. GitHub hutuma matukio ya hazina (repository events) kwa kufanya ombi la HTTP kwenye URL unayoisajili mara moja, kwa hivyo URL hiyo lazima iweze kujibu katika anwani hiyo hiyo hata kesho.

Sehemu nne zinazofanya kazi

Msikilizaji (The listener) hupokea matukio ya jukwaa, na kila jukwaa lina lake. Msikilizaji wa GitHub ni HTTP endpoint kwenye port 3050 katika njia ya /github/webhooks. Msikilizaji wa Slack Events API yuko kwenye port 3040 katika /slack/events. Slack inaweza pia kufanya kazi katika Socket Mode, ambapo programu hufungua WebSocket ya kutoka nje na haihitaji port yoyote ya kuingia ndani.

Msambazaji (The dispatcher) ndiye mratibu. Husikiliza kwenye port 3030 kwa chaguo-msingi, huhifadhi hali ya uendeshaji katika faili ya hifadhidata ya ndani iliyowekwa na OPENTAG_DATABASE_PATH, na kurekodi njia ya ukaguzi (audit trail) kwa kila uendeshaji. Hakuna kitu nje ya kisanduku hiki kinachopaswa kufikia port hii.

Mwendeshaji (The runner) ni daemon ya ndani. Hufanya polling kwa ajili ya kazi, hudai uendeshaji, hushikilia lease juu yake, na hutuma heartbeat kila sekunde 15 kwa chaguo-msingi wakati uendeshaji ukiwa hai. Hukataa uendeshaji wowote uliodaiwa ambao lengo lake la mradi halipo au liko nje ya allowlist katika usanidi wake, ambayo ndiyo ukaguzi unaozuia tukio la GitHub kuelekeza wakala wako kwenye hazina (repository) ambayo hukuwahi kuifunga.

Mtendaji (The executor) ni wakala wa usimbaji (coding agent) yenyewe. OpenTag huizindua kupitia ACP (agent client protocol), itifaki ya JSON-RPC inayozungumzwa kupitia standard input na output, kwa hivyo wakala huendesha kama mchakato wa mtoto (child process) ndani ya saraka ya kazi ambayo OpenTag humpa. Majina yaliyojengewa ndani ni pamoja na echo, codex, claude-code, cursor, opencode, hermes na openclaw. Anza na echo, mtendaji ambaye usanidi wa mfano huja nao, kwa sababu inathibitisha kuwa njia nzima inafanya kazi kabla ya mfano (model) kugusa msimbo wako.

Utaratibu haubadiliki kamwe: tukio la jukwaa, ukaguzi wa sahihi, rekodi ya uendeshaji, dai, wakala, jibu katika thread.

Kwa nini laptop na tunnel havitoshi

Mwongozo wa usanidi wa GitHub unakuambia uendeshe ngrok http 3050 na ubandike host ya tunnel kwenye webhook ya repository. Hilo hufanya kazi kwa dakika kumi za kwanza. Host ya tunnel ya bure hubadilika kila wakati mchakato unapoanzishwa upya, na huacha kufanya kazi pale laptop inapoingia kwenye hali ya usingizi (sleep). GitHub huhifadhi URL ya zamani ya payload na kuendelea kujaribu kuitumia, hivyo kichupo cha Recent Deliveries katika mipangilio ya webhook hujaa hitilafu huku thread ikibaki kimya. Hakuna anayegundua kwa wiki nzima, kwa sababu webhook isiyofanya kazi inaonekana kama bot ambayo hakuna aliyewahi kuitaja.

VPS hutatua mambo hayo mawili yanayovunjika. Jina la DNS halibadiliki, kwa hivyo URL ya payload unayobandika mara moja inabaki kuwa sahihi. Mashine haingii kwenye hali ya usingizi, kwa hivyo maoni yanayotumwa saa 02:00 hupata jibu. Sanidi mashine hiyo vizuri kwanza: dakika kumi za kwanza kwenye VPS mpya inashughulikia mtumiaji wa kuingia na firewall ambayo mwongozo huu unadhani ipo.

Slack ni ubaguzi. Katika Socket Mode, huunganisha kuelekea nje na haihitaji URL ya umma, kwa hivyo deployment ya Slack pekee inaweza kubaki imefungwa. GitHub haina mfumo sawa na huo. Webhooks za repository ni HTTP ya kuingia ndani, ambayo inamaanisha endpoint ya umma, na hiyo inamaanisha TLS (transport layer security) na ukaguzi wa sahihi (signature check).

Kujiendeshea OpenTag kwenye Ubuntu kutoka kwa toleo lililofungwa (pinned release)

OpenTag v0.9.0 inahitaji Node.js 22 au toleo jipya zaidi. Ubuntu 24.04 inakuja na Node 18 kwenye hazina zake (repository), kwa hivyo isakinishe kutoka 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 lazima ionyeshe v22 au zaidi. Kwenye Node 20, usakinishaji huonyesha onyo la EBADENGINE na CLI inaweza kufeli mara tu inapoanza.

Ipe huduma hii akaunti yake yenyewe. Wakala (agent) huendeshwa kwa kutumia ruhusa za mtumiaji huyu, kwa hivyo haipaswi kuwa akaunti yako ya kuingia na haipaswi kuwa root. Watumiaji wenye upendeleo mdogo kwenye VPS inaelezea kwa nini utengano huo una thamani ya hatua hiyo ya ziada.

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 inapaswa kuonyesha njia kama /usr/bin/opentag. Mpangilio wa linger ni muhimu kwenye Linux: OpenTag husakinisha huduma yake ya usuli kupitia systemd, na huduma ya mtumiaji bila linger husimama mara tu kikao chako cha SSH kinapofungwa.

Endesha usanidi kama mtumiaji huyo.

sudo -iu opentag opentag setup

Usanidi huuliza mambo sita: lugha ya CLI, anwani ya ndani ya kusikiliza (listening address), wakala wa kuandika msimbo (coding agent), mradi wa ndani wa kufanyia kazi, vitambulisho vya jukwaa vya kuhifadhi, na jinsi ya kuendesha. Weka anwani ya kusikiliza kwenye 127.0.0.1, kwa sababu nginx hufanya TLS termination na kupeleka maombi huko, kwa hivyo wasikilizaji hawahitaji kufikiwa kutoka nje. Kwa GitHub, pia huuliza hazina (repository) katika mfumo wa owner/repo, ikiwa inaweza kufungua pull requests, port ya webhook (3050 kwa chaguo-msingi) na token. Chagua hali ya huduma ya usuli (background service mode) mwishoni. Ikiwa tayari una usanidi na unataka huduma isakinishwe bila maswali, opentag setup --service hufanya hivyo.

Usanidi huhifadhiwa kwenye /home/opentag/.config/opentag/config.json na hali ya wakati wa kuendesha (runtime state) kwenye /home/opentag/.local/state/opentag. Funguo hizi zinastahili kukaguliwa kwa mikono baada ya usanidi kuandika faili.

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

Pendelea runnerToken, token ya bearer iliyofungwa kwenye runner, badala ya ile ya zamani ya pamoja ya pairingToken. Faili ya usanidi huhifadhi vitambulisho katika maandishi wazi (plain text) isipokuwa ukiyabadilisha na marejeleo ya siri (secret reference), ambayo husoma thamani kutoka kwa mazingira au kutoka kwa faili kwenye diski wakati wa kuanza. Kwa vyovyote vile, faili hii ndiyo kitu nyeti zaidi kwenye seva: mode 600, inayomilikiwa na opentag, na isiwe kamwe ndani ya hazina ya git. Hoja pana zaidi iko katika kuweka siri nje ya mawakala wa AI.

Kagua usakinishaji kabla ya kufichua chochote.

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

opentag doctor hukagua dispatcher, bindings, checkouts na executors. opentag status huchapisha usanidi na hali ya wakati wa kuendesha, na inaweza kupunguzwa kwa uendeshaji mmoja mara tu uendeshaji utakapokuwepo. Rekebisha kila kitu ambacho doctor inaripoti kabla ya kuelekeza jukwaa kwenye seva hii.

Weka TLS mbele na ufungue njia mbili pekee

nginx hukomesha TLS na kusambaza njia mbili pekee. Kila kitu kingine hurejesha 404, kwa hivyo skana inayopata host haijifunzi chochote kuhusu kinachoendeshwa nyuma yake.

Andika block ya seva ya port 80 kwenye /etc/nginx/sites-available/opentag na maeneo mawili yaliyo hapa chini, kisha ruhusu Certbot iongeze nusu ya 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 huchapisha syntax is ok na test is successful, na ndicho kitu pekee kilichopo kati ya kosa la kuandika na reload inayoweza kuangusha tovuti. Certbot kwenye Ubuntu 24.04 na nginx inashughulikia uboreshaji na njia ambazo changamoto ya ACME (automatic certificate management environment) inashindwa. Block iliyokamilika inaonekana hivi.

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

= katika location = /github/webhooks ni mechi kamili, na proxy_pass bila kitu chochote baada ya port hupitisha URI ya asili bila kubadilishwa. Ondoa = na kila njia iliyo chini ya /github/webhooks/ itasambazwa pia, jambo ambalo ni eneo kubwa zaidi kuliko lile ambalo msikilizaji anahitaji.

Firewall inabaki kuwa finyu.

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

Port 3030, 3040 na 3050 hazifunguliwi kamwe. Thibitisha kuwa zimefungwa kwenye loopback badala ya kila interface.

sudo ss -tlnp

Kila mstari wa OpenTag unapaswa kusomeka 127.0.0.1:3030 au sawa na hiyo. Mstari unaosomeka 0.0.0.0:3050 unamaanisha kuwa msikilizaji anajitoa kwa Internet nzima na ufw pekee ndiyo inayozuia, jambo ambalo ni kosa moja la firewall mbali na kichocheo cha wakala aliye wazi. Misingi ya ufw firewall inaelezea kile ambacho default deny inafanya kweli.

Ukaguzi mbili huthibitisha mlango wa mbele. curl -I https://opentag.example.com/ hurejesha 404 kutoka kwa nginx, jambo linaloonyesha kuwa cheti ni halali na catch-all imefungwa. Ombi kwa /slack/events au /github/webhooks lisilokuwa na sahihi halipaswi kurejesha 200 kamwe.

Thibitisha kila sahihi, kwa sababu URL ni ya umma

Mtu yeyote anaweza kupata URL ya payload. Inapatikana kwenye mipangilio ya hazina yako, katika historia ya kivinjari, au kwenye picha ya skrini iliyobandikwa kwenye tiketi. Sahihi ndiyo kitu pekee kinachotofautisha uwasilishaji halisi wa GitHub na ombi lililoandikwa kwa mkono na mtu yeyote.

GitHub husaini kila uwasilishaji kwa kutumia webhook secret na kutuma matokeo katika header ya x-hub-signature-256. OpenTag huthibitisha header hiyo dhidi ya platforms.github.webhookSecret. Vidokezo vya kuimarisha usalama wa mradi huu vinasema sheria moja kwa moja: usikubali matukio ya chanzo ambayo hayajasainiwa kwenye /github/webhooks. Slack husaini kila ombi kwa SLACK_SIGNING_SECRET na kuingiza timestamp, hivyo mwili wa ombi uliokamatwa hauwezi kutumika tena baada ya saa kadhaa.

Kuruka hatua hii si hatari ndogo. Endpoint isiyothibitishwa hukubali payload ya issue_comment iliyoandikwa kwa mkono yenye @opentag, na kisha OpenTag huendesha wakala wa usimbaji, kwa kutumia token yako, kwenye checkout yako, kulingana na maelekezo kutoka kwa mgeni. Jibu huenda kwenye thread yoyote inayotajwa na payload hiyo bandia.

OpenTag huongeza tabaka mbili juu yake. Uwasilishaji wa chanzo hufuatiliwa kwa delivery ID, hivyo kutuma tena tukio lilelile hakuanzishi mchakato wa pili. Wito wa runner hukubali idempotency keys, hivyo kurudia ombi moja hurejesha mafanikio bila kuongeza tukio lingine la ukaguzi.

Rate limits zinaweza kusanidiwa na zinapaswa kuwashwa. OPENTAG_RATE_LIMIT_WINDOW_MS na OPENTAG_RATE_LIMIT_MAX_REQUESTS hupunguza kasi ya maombi, OPENTAG_MAX_REQUEST_BODY_BYTES hupunguza ukubwa wa mwili wa ombi, na payload kubwa kupita kiasi hukataliwa kwa 413 request_body_too_large. OPENTAG_RATE_LIMIT_DISABLED=true ipo kwa ajili ya maendeleo ya ndani (local development), na haina nafasi kwenye seva ya umma. Sheria nyingine kutoka kwenye vidokezo hivyo: URL ya relay ya umma lazima itumie HTTPS, na CLI inaruhusu HTTP ya kawaida kwa localhost pekee.

Ni scope zipi za token ambazo bot inahitaji hasa?

Kwenye GitHub, OpenTag hutumia fine-grained personal access token badala ya GitHub App. Nyaraka zinasema kuwa njia ya App imepangwa na si usanidi chaguo-msingi wa CLI kwa sasa, na hilo lina matokeo ambayo watu huyasahau: bot hutoa maoni kama binadamu aliyetengeneza token hiyo. Itengeneze chini ya akaunti ambayo uko tayari kuiona ikinukuliwa katika kila jibu la triage.

Ipe scope kwa umakini kama mwongozo wa usanidi unavyoelekeza. Chagua Only select repositories na uchague moja. Toa ruhusa ya Issues: Read and write na Pull requests: Read and write. Hiyo inatosha kusoma mention na kujibu kwenye thread.

Angalia kile kinachokosekana: write access kwenye code. OpenTag haisukumi (push) branches isipokuwa kama preparePullRequestBranch imewekwa kuwa true, na kuna githubApplyToken tofauti ili token inayoandika code isiwe ile inayotoa maoni. Ziweke kando, na uweke token ya kuandika (write token) ikiwa imezimwa hadi pale njia ya kusoma-na-kutoa-maoni itakapofanya kazi kwa wiki chache.

Usanidi wa kuepuka ni token yenye Contents: Read and write kwenye All repositories. Kila mtu anayeweza kutoa maoni kwenye yoyote ya repositories hizo sasa anaweza kuongoza wakala (agent) mwenye haki za commit, na audit trail itasema mmiliki wa token ndiye aliyefanya hivyo. Panua scope kwa repository moja baada ya nyingine, baada ya wakala kujithibitisha.

Kwenye Slack, scope za bot ni app_mentions:read, chat:write, reactions:write na channels:history. Private channels pia zinahitaji groups:history pamoja na usajili kwenye tukio la message.groups. Socket Mode inahitaji app-level token yenye connections:write, ile inayoanza na xapp-. channels:history husoma historia ya ujumbe katika public channels ambazo bot imeongezwa, kwa hivyo ongeza bot kwenye channels ambazo inahitajika badala ya kila mahali.

Fuatilia tatizo moja kuanzia mwanzo hadi mwisho

Webhook ndiyo hatua ya kwanza. Kwenye hazina (repository), fungua Settings, kisha Webhooks, kisha Add webhook. URL ya payload ni https://opentag.example.com/github/webhooks, aina ya maudhui ni application/json, na secret ni ile iliyotengenezwa wakati wa usanidi. Jisajili kwa Issue comments na Pull request review comments, na si kitu kingine chochote.

GitHub hutuma ping delivery mara tu unapohifadhi. Fungua Recent Deliveries na uhakikishe kuwa ombi limefika kwenye seva. Hitilafu ya 502 hapo inamaanisha nginx imeshindwa kufikia msikilizaji (listener), jambo ambalo ni tatizo la ndani, si la GitHub.

Sasa itumie. Fungua issue inayoelezea mdudu (bug) na uweke maoni:

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

Mambo yanayopaswa kutokea, kwa mpangilio. Recent Deliveries hurekodi delivery ya issue_comment ikiwa na majibu ya 2xx. Dispatcher hurekodi run. Runner huichukua na kuanza kutuma heartbeats. Executor hufungua checkout na kuanza kazi. Jibu hufika kama maoni kwenye uzi uleule wa issue. sudo -iu opentag opentag status huonyesha run wakati ikiwa inaendelea, ili uweze kuifuatilia badala ya kukisia.

Weka approvalMode kuwa ask kabla ya run ya kwanza ya kweli. Katika hali ya ask, run husimama na kusubiri mtu kabla haijafanya chochote kinachobadilisha hali. Hali za auto na autonomous zipo, na zinafaa baadaye, kwenye hazina ambapo umesoma nakala za mwezi mzima.

Kwa upande wa Slack, run hiyo hiyo huanza na /bind owner/repo kwenye channel, kisha mention. Bot pia hujibu /help, /status, /doctor, /stop na /unbind confirm. Zuia watu wanaoweza kubadilisha bindings kwa kutumia OPENTAG_SLACK_BINDING_ADMIN_USER_IDS, orodha ya Slack user IDs iliyotenganishwa kwa koma, kwa sababu binding ni ramani kutoka kwa channel ya umma kwenda kwenye checkout kwenye seva yako.

Triage ni njia nzuri ya kuanzia kwa sababu inasoma na haiandiki, na jibu ni rahisi kukadiria. Review ni hatua inayofuata, ambapo wakala huweka maoni kwenye diff badala ya issue: wakala wa kujihudumia wa ukaguzi wa pull request ni usanifu uleule uliolenga pull requests. Ikiwa unataka wakala afikie mifumo yako mwenyewe wakati anafanya kazi, hiyo ni kazi ya seva za MCP kwenye VPS. Utafutaji wa wavuti ni uwezo mwingine ambao triage huendelea kuomba, na kuunganisha wakala kwenye mfano wako wa SearXNG huweka utafutaji huo kwenye vifaa unavyoviendesha, kwa gharama ya njia moja zaidi ambayo maandishi ya mgeni humfikia wakala.

Nini hutokea wakati wakala anapokosea mbele ya kila mtu?

Atakosea. Swali ni gharama ya kosa hilo.

Jibu lisilo sahihi kwenye suala la hadhara ni maoni yaliyochapishwa chini ya jina ambalo timu yako inalitambua, na GitHub hutuma barua pepe kwa kila mtu aliyesajiliwa wakati huo huo. Kufuta maoni hakufuti barua pepe iliyotumwa. Hali ni hiyo hiyo kwa taarifa ya Slack. Panga mkakati wa kukabiliana na jibu lisilo sahihi hadharani badala ya kutegemea usahihi wa faragha.

Chaguzi nne hupunguza madhara, na ni muhimu zaidi kuliko prompt yoyote unayoandika.

• Endesha katika hali ya ask, ili wakala apendekeze, mtu aidhinishe, na mpango mbaya ugharimu mbofyo mmoja tu.
• Acha preparePullRequestBranch katika thamani yake ya awali ya false, ili matokeo mabaya zaidi ya utekelezaji mbaya yawe maoni yasiyo sahihi badala ya branch isiyo sahihi.
• Funga repository moja na channel moja ili kuanza. Runner hukataa utekelezaji wowote ambao lengo lake la mradi liko nje ya allowlist yake ya ndani, kwa hivyo repository isiyofungwa haiwezi kumvuta wakala ndani yake.
• Weka token ya kutoa maoni ikiwa tofauti na token yoyote ya kutekeleza (apply), ili kubatilisha uwezo wa kuandika kusiathiri uwezo wa kufanya triage.

Slack ina amri ya /stop kwa ajili ya utekelezaji unaoenda vibaya. Kila utekelezaji huacha kumbukumbu ya ukaguzi (audit record) inayohifadhi ombi lililoanzisha mchakato na kile wakala alichokifanya, ambacho ndicho unachokisoma baadaye ili kubaini mahali palipokwenda vibaya.

Nusu ya kijamii ni muhimu kama usanidi wenyewe. Weka bot katika channel moja ambapo watu wanatarajia mashine na wanajua kuwa inaweza kukosea. Jibu lisilo sahihi lililotolewa kwa ujasiri katika channel ya watu arobaini wanaodhani kuwa binadamu amelikagua hugharimu zaidi ya muda uliookolewa na triage. Andika katika maelezo ya channel nani anayemiliki bot hiyo na nani anayekagua matokeo yake.

Hifadhi nakala, maboresho na uwekaji wa toleo (pinning)

Njia mbili huhifadhi kila kitu: /home/opentag/.config/opentag/config.json na /home/opentag/.local/state/opentag. Ya kwanza ina vitambulisho vyako, ya pili ina historia ya uendeshaji na faili la database. Hifadhi nakala zote mbili kwa kutumia mode 600, na uziweke nje ya seva hii. Kupoteza faili hizi kunamaanisha kuunda upya token na bindings, si kujenga upya seva.

Maboresho ni kuongeza toleo na kuanzisha upya huduma.

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

Weka toleo maalum (pin) badala ya kufuata @latest. Programu hii huendesha wakala wa usimbaji dhidi ya hazina (repository) yako kwa kutumia token hai, kwa hivyo toleo jipya linalotolewa usiku linaweza kuwa na mabadiliko ambayo hujayapitia. Sera ya usalama haifanyi backport ya marekebisho yoyote, na marekebisho hupatikana tu katika toleo jipya zaidi, kwa hivyo kuweka toleo maalum kunamaanisha unasoma changelog na kusonga mbele kwa makusudi. Hii haimaanishi kubaki kwenye v0.9.0 milele. Historia hadi Julai 2026 inaonyesha matoleo kadhaa kwa mwezi, ambayo ni sababu nzuri ya kusoma maelezo ya toleo kabla ya kila uboreshaji.

FAQ

Je, nahitaji VPS ili kuendesha OpenTag, au laptop inatosha?

Laptop inatosha kwa ajili ya Slack pekee, kwa sababu Socket Mode hufungua WebSocket ya kutoka nje na haihitaji port ya kuingia. GitHub ni tofauti. Webhooks za repository hutuma data kupitia HTTP ya kuingia kwenye URL uliyoisajili mara moja, kwa hivyo anwani lazima ibaki vilevile na lazima ijibu wakati umelala. Host ya tunnel kutoka akaunti ya bure hubadilika kila unapoanzisha upya, na GitHub huendelea kutuma data kwenye ile ya zamani, jambo linaloonekana kama entries zilizofeli kwenye kichupo cha Recent Deliveries cha repository na kama ukimya kwenye thread. VPS yenye jina la DNS lisilobadilika na cheti huondoa matatizo yote mawili.

OpenTag inahitaji ruhusa zipi za GitHub?

Personal access token iliyobainishwa vizuri na kuzuiliwa kwa Only select repositories, ikiwa na Issues: Read and write na Pull requests: Read and write. Hiyo inatosha kusoma mention na kujibu kwenye thread. Ruhusa ya kuandika code haihitajiki isipokuwa ukiweka preparePullRequestBranch kuwa true ili OpenTag isukume branches, na githubApplyToken tofauti ipo ili token ya kuandika code ibaki kando na ile ya kutoa maoni. Epuka token ya all-repositories yenye ruhusa ya contents write, kwa sababu mtu yeyote anayeweza kutoa maoni kwenye repository hizo anaweza kuongoza agent inayoweza kufanya commit.

Ninawezaje kusimamisha mchakato unaoenda vibaya?

Slack ina amri ya /stop kwa ajili hiyo hasa. Kwenye seva, opentag status huonyesha kinachoendelea, na opentag service stop husimamisha daemon, jambo linalomaliza pipeline nzima badala ya mchakato mmoja. Ili kuepuka kuhitaji yoyote kati ya hayo, weka approvalMode kuwa ask ili michakato isitishe kwa ajili ya mtu kabla ya kubadilisha chochote, na acha preparePullRequestBranch ikiwa false ili mchakato mbaya utoe maoni badala ya branch.

Kwa nini webhook yangu inarudisha 502 wakati thread inabaki kimya?

502 inatoka kwa nginx, si kwa OpenTag, na inamaanisha proxy haikuweza kufikia msikilizaji. /var/log/nginx/error.log itaonyesha connect() failed (111: Connection refused) while connecting to upstream. Aidha msikilizaji amesimama, au yuko kwenye port tofauti na ile iliyotajwa kwenye mstari wa proxy_pass. Endesha sudo ss -tlnp na uthibitishe kuwa kuna kitu kinasikiliza kwenye 127.0.0.1:3050 kwa ajili ya GitHub na 127.0.0.1:3040 kwa ajili ya Slack, kisha endesha opentag doctor kwa ajili ya bindings na executors.