Cara self-host OpenTag untuk @agent mentions

Tindakan OpenTag apabila anda menyebut ejen

OpenTag menukarkan @mention dalam thread Slack atau isu GitHub kepada pelaksanaan ejen pengekodan pada mesin milik anda. Seseorang memberikan komen @opentag investigate this pada sesuatu isu. Satu pendengar (listener) menerima peristiwa platform tersebut, menyemak tandatangannya, memadankan sebutan itu dengan projek yang terikat, memulakan ejen pengekodan terhadap checkout tempatan, dan menyiarkan semula hasilnya dalam thread yang sama.

Projek ini dilesenkan di bawah MIT dan berada di amplifthq/opentag. Setakat Ogos 2026, release bertanda yang terbaharu ialah v0.9.0, diterbitkan pada 28 Julai 2026, dan ia diedarkan sebagai pakej npm. Tiada imej kontena rasmi, jadi perkara yang anda pin ialah versi npm. Setiap arahan di bawah melakukan pinning terhadap versi tersebut.

Ini menjadi projek VPS dan bukannya projek komputer riba disebabkan oleh bahagian GitHub. GitHub menghantar peristiwa repositori dengan membuat permintaan HTTP ke URL yang anda daftarkan sekali sahaja, jadi URL tersebut mestilah menjawab pada alamat yang sama pada hari esok.

Empat komponen utama

Listener menerima peristiwa platform, dan setiap platform mempunyai listener tersendiri. Listener GitHub merupakan endpoint HTTP pada port 3050 di path /github/webhooks. Listener Slack Events API pula berada pada port 3040 di /slack/events. Slack juga boleh dijalankan dalam Socket Mode, di mana aplikasi membuka WebSocket keluar dan tidak memerlukan sebarang port masuk.

Dispatcher bertindak sebagai penyelaras. Ia mendengar pada port 3030 secara lalai, menyimpan status pelaksanaan dalam fail pangkalan data tempatan yang ditetapkan oleh OPENTAG_DATABASE_PATH, serta merekodkan jejak audit bagi setiap pelaksanaan. Tiada entiti di luar kotak yang sepatutnya mencapai port ini.

Runner ialah daemon tempatan. Ia membuat tinjauan (poll) untuk mendapatkan tugasan, menuntut pelaksanaan, memegang pajakan ke atasnya, dan menghantar heartbeat setiap 15 saat secara lalai selagi pelaksanaan tersebut aktif. Ia akan menolak sebarang pelaksanaan yang dituntut jika sasaran projek tiada atau berada di luar senarai kebenaran (allowlist) dalam konfigurasinya sendiri. Ini merupakan semakan yang menghalang peristiwa GitHub daripada menghalakan ejen anda ke repositori yang tidak pernah anda ikat.

Executor ialah ejen pengekodan itu sendiri. OpenTag melancarkannya melalui ACP (agent client protocol), iaitu protokol JSON-RPC yang menggunakan input dan output standard, supaya ejen berjalan sebagai proses anak di dalam direktori kerja yang diberikan oleh OpenTag. Nama terbina dalam termasuk echo, codex, claude-code, cursor, opencode, hermes dan openclaw. Mulakan dengan echo, iaitu executor yang disertakan dalam konfigurasi contoh, kerana ia membuktikan keseluruhan laluan berfungsi sebelum model menyentuh kod anda.

Urutannya tidak pernah berubah: peristiwa platform, semakan tandatangan, rekod pelaksanaan, tuntutan, ejen, dan balasan dalam thread.

Mengapa komputer riba dan tunnel tidak mencukupi

Panduan penyediaan GitHub memberitahu anda untuk menjalankan ngrok http 3050 dan menampal hos tunnel ke dalam webhook repositori. Cara ini berkesan untuk sepuluh minit pertama. Hos tunnel percuma akan berubah setiap kali proses dimulakan semula, dan ia berhenti berfungsi apabila komputer riba masuk ke mod tidur. GitHub mengekalkan URL payload yang lama dan terus mencubanya, jadi tab Recent Deliveries dalam tetapan webhook dipenuhi dengan kegagalan sementara thread kekal senyap. Tiada sesiapa yang menyedarinya selama seminggu, kerana webhook yang tidak berfungsi kelihatan sama seperti bot yang tidak disebut oleh sesiapa.

VPS menyelesaikan dua perkara yang sering tergendala. Nama DNS tidak berubah, jadi URL payload yang anda tampal sekali kekal tepat. Mesin tidak masuk ke mod tidur, jadi komen pada jam 02:00 akan mendapat jawapan. Sediakan pelayan dengan betul terlebih dahulu: sepuluh minit pertama pada VPS baharu merangkumi pengguna log masuk dan firewall yang diandaikan oleh panduan ini.

Slack adalah pengecualian. Dalam Socket Mode, ia menyambung ke luar dan tidak memerlukan URL awam, jadi penggunaan yang hanya melibatkan Slack boleh kekal tertutup. GitHub tidak mempunyai fungsi yang setara. Webhook repositori adalah HTTP masuk, yang bermaksud ia memerlukan titik akhir awam, TLS (transport layer security), dan semakan tandatangan.

Self-host OpenTag pada Ubuntu daripada keluaran yang disematkan

OpenTag v0.9.0 memerlukan Node.js 22 atau lebih baharu. Ubuntu 24.04 membekalkan Node 18 dalam repositori asalnya, jadi pasang daripada 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 mesti mencetak v22 atau lebih tinggi. Pada Node 20, pemasangan akan mencetak amaran EBADENGINE dan CLI boleh gagal sebaik sahaja ia bermula.

Berikan servis akaunnya sendiri. Ejen berjalan dengan keizinan pengguna ini, jadi ia tidak sepatutnya akaun log masuk anda dan ia tidak sepatutnya root. Pengguna dengan keizinan minimum pada VPS menjelaskan sebab pengasingan ini berbaloi dengan langkah tambahan tersebut.

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 sepatutnya mencetak laluan seperti /usr/bin/opentag. Tetapan linger penting pada Linux: OpenTag memasang servis latar belakangnya melalui systemd, dan servis pengguna tanpa linger akan berhenti sebaik sahaja sesi SSH anda ditutup.

Jalankan persediaan sebagai pengguna tersebut.

sudo -iu opentag opentag setup

Persediaan meminta enam perkara: bahasa CLI, alamat pendengaran tempatan, ejen pengekodan, projek tempatan untuk diusahakan, kelayakan platform untuk disimpan, dan cara untuk dijalankan. Kekalkan alamat pendengaran pada 127.0.0.1, kerana nginx menamatkan TLS dan memajukannya ke sana, jadi pendengar tidak perlu boleh dicapai dari luar. Untuk GitHub, ia juga meminta repositori dalam bentuk owner/repo, sama ada ia boleh membuka pull request, port webhook (3050 secara lalai) dan token. Pilih mod servis latar belakang pada akhirnya. Jika anda sudah mempunyai konfigurasi dan mahu servis dipasang tanpa gesaan, opentag setup --service melakukan perkara tersebut.

Konfigurasi disimpan dalam /home/opentag/.config/opentag/config.json dan status masa jalan dalam /home/opentag/.local/state/opentag. Kunci-kunci ini perlu diperiksa secara manual selepas persediaan menulis fail tersebut.

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

Utamakan runnerToken, iaitu bearer token skop-pelari, berbanding pairingToken dikongsi yang lebih lama. Fail konfigurasi menyimpan kelayakan dalam teks biasa melainkan anda menggantikannya dengan rujukan rahsia, yang membaca nilai daripada persekitaran atau daripada fail pada cakera semasa permulaan. Walau apa pun, fail ini adalah perkara paling sensitif pada pelayan: mod 600, dimiliki oleh opentag, dan tidak boleh berada di dalam repositori git. Hujah yang lebih luas ada dalam menyimpan rahsia di luar ejen AI.

Periksa pemasangan sebelum mendedahkan apa-apa.

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

opentag doctor memeriksa penghantar (dispatcher), pengikatan (bindings), daftar keluar (checkouts) dan pelaksana (executors). opentag status mencetak konfigurasi dan status masa jalan, dan ia boleh diletakkan skop kepada satu larian sebaik sahaja larian wujud. Betulkan semua yang dilaporkan oleh doctor sebelum anda menghalakan platform ke pelayan ini.

Letakkan TLS di hadapan dan buka hanya dua laluan

nginx menamatkan TLS dan memajukan tepat dua laluan. Segala perkara lain akan mengembalikan 404, jadi pengimbas yang menemui hos tersebut tidak akan mengetahui apa yang dijalankan di belakangnya.

Tulis blok pelayan port 80 biasa pada /etc/nginx/sites-available/opentag dengan dua lokasi di bawah, kemudian biarkan Certbot menambah bahagian 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 mencetak syntax is ok dan test is successful, dan ia merupakan satu-satunya penghalang antara kesilapan menaip dan muat semula yang menyebabkan tapak web terhenti. Certbot pada Ubuntu 24.04 dengan nginx merangkumi pembaharuan dan cara cabaran ACME (automatic certificate management environment) gagal. Blok yang telah siap kelihatan seperti ini.

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

= dalam location = /github/webhooks adalah padanan tepat, dan proxy_pass tanpa apa-apa selepas port akan menghantar URI asal tanpa perubahan. Gugurkan = dan setiap laluan di bawah /github/webhooks/ juga akan dimajukan, yang merupakan permukaan serangan yang lebih luas daripada yang diperlukan oleh pendengar.

Firewall kekal terhad.

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

Port 3030, 3040 dan 3050 tidak dibuka sama sekali. Sahkan bahawa ia terikat pada loopback dan bukannya pada setiap antara muka.

sudo ss -tlnp

Setiap baris OpenTag harus membaca 127.0.0.1:3030 atau yang serupa. Baris yang membaca 0.0.0.0:3050 bermakna pendengar menawarkan dirinya kepada seluruh internet dan hanya ufw yang menghalangnya, yang mana satu kesilapan firewall sahaja sudah cukup untuk mencetuskan ejen terbuka. Asas firewall ufw menjelaskan apa yang sebenarnya dilakukan oleh penafian lalai tersebut.

Dua pemeriksaan membuktikan pintu hadapan. curl -I https://opentag.example.com/ mengembalikan 404 daripada nginx, yang menunjukkan sijil adalah sah dan catch-all telah ditutup. Permintaan kepada /slack/events atau /github/webhooks yang tidak membawa tandatangan tidak boleh mengembalikan 200.

Sahkan setiap tandatangan, kerana URL adalah awam

Sesiapa sahaja boleh mencari URL muatan (payload). Ia terletak dalam tetapan repositori anda, dalam sejarah pelayar, atau dalam tangkapan skrin yang ditampal ke dalam tiket. Tandatangan adalah satu-satunya perkara yang membezakan penghantaran GitHub yang sebenar daripada permintaan yang ditaip secara manual oleh seseorang.

GitHub menandatangani setiap penghantaran dengan webhook secret dan menghantar hasilnya dalam pengepala x-hub-signature-256. OpenTag mengesahkan pengepala tersebut berbanding platforms.github.webhookSecret. Nota pengukuhan (hardening) projek menyatakan peraturan tersebut secara terus: jangan terima peristiwa sumber yang tidak ditandatangani pada /github/webhooks. Slack menandatangani setiap permintaan dengan SLACK_SIGNING_SECRET dan menyertakan cap masa, supaya badan (body) yang ditangkap tidak boleh dimainkan semula beberapa jam kemudian.

Mengabaikan perkara ini bukanlah risiko kecil. Endpoint yang tidak disahkan akan menerima muatan issue_comment yang ditulis tangan yang mengandungi @opentag, dan OpenTag kemudiannya akan menjalankan ejen pengekodan, dengan token anda, dalam checkout anda, berdasarkan arahan daripada orang asing. Balasan tersebut akan pergi ke mana-mana thread yang dinamakan oleh muatan palsu itu.

OpenTag menambah dua lapisan di atasnya. Penghantaran sumber dijejaki mengikut ID penghantaran, jadi penghantaran semula peristiwa yang sama tidak akan memulakan larian kedua. Panggilan runner menerima kunci idempotensi, jadi memainkan semula satu permintaan akan mengembalikan kejayaan tanpa menambah peristiwa audit yang lain.

Had kadar (rate limits) boleh dikonfigurasikan dan perlu diaktifkan. OPENTAG_RATE_LIMIT_WINDOW_MS dan OPENTAG_RATE_LIMIT_MAX_REQUESTS mengehadkan kadar permintaan, OPENTAG_MAX_REQUEST_BODY_BYTES mengehadkan saiz badan, dan muatan yang terlalu besar akan ditolak dengan 413 request_body_too_large. OPENTAG_RATE_LIMIT_DISABLED=true wujud untuk pembangunan setempat, dan ia tidak sepatutnya berada pada kotak awam. Satu lagi peraturan daripada nota yang sama: URL relay awam mesti menggunakan HTTPS, dan CLI hanya membenarkan HTTP biasa untuk localhost.

Apakah skop token yang sebenarnya diperlukan oleh bot?

Di GitHub, OpenTag menggunakan fine-grained personal access token dan bukannya GitHub App. Dokumentasi menyatakan bahawa laluan App sedang dirancang dan bukan tetapan CLI lalai pada masa ini, dan ini membawa kesan yang sering terlepas pandang: bot memberikan komen sebagai manusia yang mencipta token tersebut. Cipta token di bawah akaun yang anda sanggup lihat dipetik dalam setiap balasan triaj.

Hadkan skopnya seketat yang disarankan dalam panduan penyediaan. Pilih Only select repositories dan pilih satu repositori. Berikan kebenaran Issues: Read and write serta Pull requests: Read and write. Itu sudah memadai untuk membaca sebutan dan menjawab dalam bebenang perbincangan.

Perhatikan apa yang tiada: akses tulis kepada kod. OpenTag tidak menolak (push) cawangan kecuali preparePullRequestBranch ditetapkan kepada true, dan terdapat githubApplyToken yang berasingan supaya token yang menulis kod bukan token yang menulis komen. Asingkan kedua-duanya, dan pastikan token tulis tidak diaktifkan sehingga laluan baca-dan-komen telah berjalan selama beberapa minggu.

Konfigurasi yang perlu dielakkan ialah token dengan Contents: Read and write merentasi All repositories. Sesiapa sahaja yang boleh memberi komen pada mana-mana repositori tersebut kini boleh mengawal ejen yang mempunyai hak komit, dan jejak audit akan menyatakan bahawa pemilik token yang melakukannya. Luaskan skop satu repositori pada satu masa, selepas ejen tersebut telah membuktikan kebolehpercayaannya.

Pada Slack, skop bot ialah app_mentions:read, chat:write, reactions:write dan channels:history. Saluran peribadi juga memerlukan groups:history serta langganan kepada peristiwa message.groups. Socket Mode memerlukan token peringkat aplikasi dengan connections:write, iaitu token yang bermula dengan xapp-. channels:history membaca sejarah mesej dalam saluran awam yang telah ditambah bot tersebut, jadi tambahkan bot ke saluran yang diperlukan sahaja dan bukannya di semua tempat.

Selesaikan satu isu dari hujung ke hujung

Webhook adalah langkah pertama. Di dalam repositori, buka Settings, kemudian Webhooks, dan pilih Add webhook. URL payload ialah https://opentag.example.com/github/webhooks, jenis kandungan ialah application/json, dan secret adalah yang dijana semasa penyediaan. Langgan kepada Issue comments dan Pull request review comments, dan jangan pilih yang lain.

GitHub akan menghantar penghantaran ping sebaik sahaja anda menyimpannya. Buka Recent Deliveries dan semak sama ada permintaan tersebut sampai ke pelayan. Ralat 502 di situ bermakna nginx tidak dapat mencapai pendengar, yang merupakan masalah tempatan, bukan masalah GitHub.

Sekarang, gunakannya. Buka isu yang menerangkan pepijat dan berikan komen:

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

Perkara yang sepatutnya berlaku, mengikut urutan. Recent Deliveries merekodkan penghantaran issue_comment dengan respons 2xx. Dispatcher merekodkan satu larian (run). Runner menuntut larian tersebut dan memulakan heartbeating. Executor membuka checkout dan memulakan kerja. Jawapan akan muncul sebagai komen dalam thread isu yang sama. sudo -iu opentag opentag status menunjukkan larian tersebut semasa ia sedang berlangsung, jadi anda boleh memantaunya dan tidak perlu meneka.

Tetapkan approvalMode kepada ask sebelum larian sebenar yang pertama. Dalam mod ask, larian akan berhenti seketika dan menunggu tindakan manusia sebelum melakukan sebarang perubahan status. Mod auto dan autonomous juga tersedia, dan ia sesuai digunakan kemudian, pada repositori di mana anda telah membaca transkrip selama sebulan.

Di bahagian Slack, larian yang sama bermula dengan /bind owner/repo dalam saluran, diikuti dengan sebutan (mention). Bot juga menjawab /help, /status, /doctor, /stop dan /unbind confirm. Hadkan siapa yang boleh menukar binding dengan OPENTAG_SLACK_BINDING_ADMIN_USER_IDS, iaitu senarai ID pengguna Slack yang dipisahkan dengan koma, kerana binding adalah pemetaan daripada saluran awam kepada checkout pada pelayan anda.

Triage adalah laluan pertama yang baik kerana ia hanya membaca dan tidak menulis, serta jawapannya mudah untuk dinilai. Review adalah langkah seterusnya, di mana ejen memberikan komen pada diff dan bukannya pada isu: ejen semakan pull request yang dihoskan sendiri adalah seni bina yang sama yang ditujukan kepada pull request. Jika anda mahu ejen mencapai sistem anda sendiri semasa ia bekerja, itu adalah tugas pelayan MCP pada VPS. Carian web adalah keupayaan lain yang sering diminta oleh triage, dan menghubungkan ejen kepada instans SearXNG anda sendiri memastikan carian tersebut dilakukan pada perkakasan yang anda kendalikan, dengan kos satu lagi saluran di mana teks orang asing sampai kepada ejen.

Apa yang berlaku apabila ejen memberikan maklumat salah di hadapan semua orang?

Ia akan menjadi salah. Persoalannya ialah apakah kosnya.

Balasan yang salah pada isu awam merupakan komen di bawah nama yang dikenali oleh pasukan anda, dan GitHub akan menghantar e-mel kepada semua pihak yang melanggan sebaik sahaja ia disiarkan. Memadam komen tersebut tidak akan menarik balik e-mel itu. Perkara yang sama berlaku untuk pemberitahuan Slack. Rancang untuk kemungkinan jawapan tersebut salah di khalayak ramai, bukannya untuk ia betul secara peribadi.

Empat pilihan mengehadkan kerosakan, dan ia lebih penting daripada sebarang prompt yang anda tulis.

• Jalankan dalam mod ask, supaya ejen membuat cadangan, seseorang meluluskan, dan pelan yang salah hanya menelan kos satu klik.
• Biarkan preparePullRequestBranch pada tetapan lalai false, supaya hasil terburuk daripada pelaksanaan yang tidak tepat hanyalah komen yang salah, bukannya cawangan (branch) yang salah.
• Ikat satu repositori dan satu saluran sebagai permulaan. Pelari (runner) akan menolak sebarang pelaksanaan yang sasaran projeknya berada di luar senarai kebenaran tempatan, jadi repositori yang tidak terikat tidak boleh menarik ejen ke dalamnya.
• Pastikan token untuk memberi komen diasingkan daripada sebarang token untuk melaksanakan (apply), supaya pembatalan akses tulis tidak menjejaskan proses triage.

Slack mempunyai arahan /stop untuk pelaksanaan yang tersasar. Setiap pelaksanaan juga meninggalkan rekod audit yang menyimpan sebutan (mention) yang memulakannya dan tindakan yang dilakukan oleh ejen, iaitu perkara yang anda baca kemudian untuk menentukan di mana silapnya.

Aspek sosial adalah sama penting dengan konfigurasi. Letakkan bot dalam satu saluran di mana orang ramai menjangkakan kehadiran mesin dan tahu bahawa ia boleh melakukan kesilapan. Jawapan salah yang diberikan dengan yakin dalam saluran yang mempunyai empat puluh orang yang menganggap ia telah disemak oleh manusia akan menelan kos yang lebih besar daripada penjimatan yang diperoleh melalui triage. Tulis dalam deskripsi saluran siapa pemilik bot tersebut dan siapa yang menyemak outputnya.

Sandaran, naik taraf dan pin versi

Dua laluan menyimpan segala-galanya: /home/opentag/.config/opentag/config.json dan /home/opentag/.local/state/opentag. Laluan pertama mengandungi kelayakan anda, manakala laluan kedua mengandungi sejarah pelaksanaan dan fail pangkalan data. Sandarkan kedua-duanya dengan mod 600 dan simpan di luar pelayan. Kehilangan fail ini bermakna anda perlu mencipta semula token dan binding, bukannya membina semula pelayan.

Naik taraf dilakukan dengan menukar versi dan memulakan semula perkhidmatan.

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

Pin versi perisian anda dan bukannya menjejaki @latest. Perisian ini menjalankan ejen pengekodan pada repositori anda menggunakan token aktif, jadi keluaran yang diterbitkan pada waktu malam merupakan perubahan yang tidak disemak. Polisi keselamatan tidak melakukan backport terhadap apa-apa, dan pembaikan hanya disertakan dalam keluaran terkini. Oleh itu, melakukan pin bermakna anda membaca changelog dan membuat keputusan secara sengaja. Ini tidak bermakna anda perlu kekal pada v0.9.0 selama-lamanya. Sejarah sehingga Julai 2026 menunjukkan beberapa keluaran setiap bulan, yang merupakan sebab utama untuk membaca nota keluaran sebelum setiap naik taraf.

FAQ

Adakah saya memerlukan VPS untuk menjalankan OpenTag, atau komputer riba sudah memadai?

Komputer riba sudah memadai untuk Slack sahaja, kerana Socket Mode membuka WebSocket keluar dan tidak memerlukan port masuk. GitHub pula berbeza. Webhook repositori menghantar data melalui HTTP masuk ke URL yang anda daftarkan sekali, jadi alamat tersebut mestilah kekal sama dan mesti sentiasa aktif walaupun anda sedang tidur. Hos terowong daripada akaun percuma akan berubah setiap kali dimulakan semula, dan GitHub akan terus menghantar data ke alamat lama, yang akan dipaparkan sebagai entri gagal dalam tab Recent Deliveries repositori dan menyebabkan thread menjadi senyap. VPS dengan nama DNS tetap dan sijil menyelesaikan kedua-dua masalah ini.

Apakah kebenaran GitHub yang diperlukan oleh OpenTag?

Token akses peribadi (personal access token) yang terperinci dan dihadkan kepada Only select repositories, dengan Issues: Read and write serta Pull requests: Read and write. Ini sudah mencukupi untuk membaca sebutan dan membalas dalam thread. Akses tulis kepada kod tidak diperlukan melainkan anda menetapkan preparePullRequestBranch kepada true supaya OpenTag menolak (push) cawangan, dan terdapat githubApplyToken berasingan supaya token penulisan kod diasingkan daripada token untuk memberi komen. Elakkan penggunaan token untuk semua repositori dengan kebenaran contents write, kerana sesiapa yang boleh memberi komen pada mana-mana repositori tersebut boleh mengawal ejen yang mempunyai keupayaan untuk melakukan commit.

Bagaimanakah cara untuk menghentikan proses yang sedang berjalan dengan salah?

Slack mempunyai arahan /stop khusus untuk tujuan ini. Pada pelayan, opentag status menunjukkan apa yang sedang berjalan, dan opentag service stop menghentikan daemon, yang akan menamatkan keseluruhan talian paip (pipeline) dan bukannya satu proses sahaja. Untuk mengelakkan keperluan menggunakan kedua-duanya, tetapkan approvalMode kepada ask supaya proses berhenti seketika untuk pengesahan manusia sebelum sebarang perubahan dilakukan, dan biarkan preparePullRequestBranch pada false supaya proses yang bermasalah menghasilkan komen dan bukannya cawangan baharu.

Mengapakah webhook saya mengembalikan ralat 502 manakala thread tetap senyap?

Ralat 502 datang daripada nginx, bukan daripada OpenTag, dan ia bermaksud proksi tidak dapat mencapai pendengar (listener). /var/log/nginx/error.log akan menunjukkan connect() failed (111: Connection refused) while connecting to upstream. Sama ada pendengar telah dihentikan, atau ia berada pada port yang berbeza daripada yang dinyatakan dalam baris proxy_pass. Jalankan sudo ss -tlnp dan pastikan ada sesuatu yang mendengar pada 127.0.0.1:3050 untuk GitHub dan 127.0.0.1:3040 untuk Slack, kemudian jalankan opentag doctor untuk melihat binding dan pelaksana (executor).