我第一次看到 “caveman” 這個(gè)詞被當(dāng)成一個(gè)項(xiàng)目名第一反應(yīng)是這該不會(huì)是個(gè)惡搞項(xiàng)目吧結(jié)果順著倉(cāng)庫(kù)點(diǎn)進(jìn)去發(fā)現(xiàn)它是一個(gè)正經(jīng)到讓人意外的持續(xù)集成工具而且定位極其明確simple CI一個(gè)可以跑在你自己的服務(wù)器上、配置簡(jiǎn)單到像穴居人敲石頭一樣的自動(dòng)化構(gòu)建系統(tǒng)。我前后在幾個(gè)項(xiàng)目里用過(guò)它跑構(gòu)建、做定時(shí)任務(wù)、掛 Webhook 自動(dòng)觸發(fā)測(cè)試加起來(lái)也有半年多今天想把真實(shí)的體驗(yàn)、踩過(guò)的坑和完整配置思路整理出來(lái)。無(wú)論你是一個(gè)人的獨(dú)立開(kāi)發(fā)者還是三五個(gè)人的小團(tuán)隊(duì)只要你手上有多余的服務(wù)器、受夠了 Jenkins 的插件負(fù)擔(dān)、又不想讓整個(gè) CI 流程被某個(gè)托管平臺(tái)綁死這篇文章應(yīng)該能幫你省下不少折騰時(shí)間。1. 先聊聊 caveman 到底是什么1.1 一個(gè)被名字耽誤的持續(xù)集成工具Caveman 是一個(gè)用 Python 寫(xiě)的極簡(jiǎn) CI 工具核心使用方式是你寫(xiě)一個(gè) YAML 配置文件描述哪些任務(wù)要跑、跑的順序是什么、什么條件下觸發(fā)然后它幫你排隊(duì)、執(zhí)行、收集輸出和上報(bào)結(jié)果。聽(tīng)起來(lái)和 Jenkins、GitHub Actions、GitLab CI 沒(méi)什么區(qū)別但它的氣質(zhì)完全不同。Caveman 的整套設(shè)計(jì)都在做減法沒(méi)有插件市場(chǎng)、沒(méi)有圖形配置界面、沒(méi)有一堆概念需要消化你只需要理解 pipeline、task 和 trigger 這三個(gè)詞基本就能上手。我自己的感受是小項(xiàng)目或者中大型項(xiàng)目的某些特定環(huán)節(jié)根本不需要一個(gè)重量級(jí) CI 平臺(tái)。你需要的是“代碼推上去之后自動(dòng)跑一下測(cè)試每天晚上自動(dòng)打個(gè)包失敗了有人知道”就這么點(diǎn)事。Caveman 恰好把這點(diǎn)事情做得很樸素很穩(wěn)。它適合誰(shuí)適合那些對(duì)服務(wù)器有掌控欲、愿意花二十分鐘寫(xiě)一個(gè) YAML、不喜歡在網(wǎng)頁(yè)上點(diǎn)來(lái)點(diǎn)去的人。反過(guò)來(lái)如果你需要在大量項(xiàng)目之間做復(fù)雜的可視化編排或者需要企業(yè)級(jí)的審計(jì)、權(quán)限矩陣那它不太適合你。1.2 它和 Jenkins、GitHub Actions 的根本差異要理解 Caveman 為什么值得關(guān)注得先看清主流 CI 工具的復(fù)雜本質(zhì)。Jenkins 本身強(qiáng)大但強(qiáng)大帶來(lái)的副作用是你得維護(hù)一套 JVM 服務(wù)、隔三差五處理插件兼容性、寫(xiě) Groovy 腳本、還要操心節(jié)點(diǎn)管理。GitHub Actions 倒是省心但你的項(xiàng)目只要不在 GitHub 上或者你希望構(gòu)建產(chǎn)物和緩存完全掌握在自己手里它就有天然的邊界。Caveman 選擇了另一條路把 CI 的調(diào)度核心做得足夠輕然后用 Shell 命令解決一切。它不發(fā)明新的 DSL不搞標(biāo)簽系統(tǒng)不搞分布式調(diào)度宇宙。構(gòu)建環(huán)境就是你的服務(wù)器任務(wù)就是你在終端里本來(lái)就會(huì)敲的那些命令。對(duì)比維度CavemanJenkinsGitHub Actions部署成本Python 庫(kù) 單個(gè)服務(wù)分鐘級(jí)JVM 環(huán)境 插件體系小時(shí)級(jí)零部署但受平臺(tái)約束配置方式一個(gè) YAML 文件界面 Groovy XMLYAML 平臺(tái)專用語(yǔ)法任務(wù)粒度Shell/Python 命令插件封裝好的 StepAction 和容器組合可移植性配置跟著項(xiàng)目走換機(jī)器即跑配置遷移成本較高幾乎綁死 GitHub對(duì)服務(wù)器的依賴需要自備需要自備不需要但數(shù)據(jù)在云端適合場(chǎng)景中小規(guī)模、自托管、極簡(jiǎn)需求大規(guī)模、復(fù)雜權(quán)限開(kāi)源項(xiàng)目、GitHub 全家桶用戶這些差異背后其實(shí)反映了一個(gè)理念CI 的本質(zhì)就是“定時(shí)或觸發(fā)地執(zhí)行一些命令”。Caveman 堅(jiān)決不偏離這個(gè)本質(zhì)也算是一種精神潔癖。我挺吃這一套的。2. 核心配置與任務(wù)模型拆解2.1 Pipeline、Task、Trigger 是怎么配合的Caveman 的配置模型我自己的理解是一個(gè)服務(wù)里可以定義很多個(gè) pipeline流水線每個(gè) pipeline 下面掛著若干 task任務(wù)每個(gè) task 可以做三件事——跑命令、聲明自己依賴誰(shuí)、設(shè)置獨(dú)立的觸發(fā)條件。Pipeline 是一個(gè)相對(duì)完整的執(zhí)行單元比如“構(gòu)建并測(cè)試”Task 則是單元里的具體步驟比如“安裝依賴”“跑單元測(cè)試”“構(gòu)建鏡像”。任務(wù)之間通過(guò)依賴關(guān)系決定執(zhí)行順序。這里不需要像某些工具那樣去畫(huà) DAG 圖你只需要寫(xiě)清楚needs依賴誰(shuí)調(diào)度器自然會(huì)按順序跑。Trigger觸發(fā)器是讓我覺(jué)得這個(gè)工具很靈活的地方。你可以讓整個(gè) pipeline 被 Webhook 觸發(fā)也可以讓某個(gè) task 按 cron 定時(shí)執(zhí)行兩者還互不沖突。這意味著同一個(gè)項(xiàng)目里push 觸發(fā)的“構(gòu)建測(cè)試”和每天晚上執(zhí)行的“自動(dòng)打包清理緩存”可以寫(xiě)在同一個(gè)配置里結(jié)構(gòu)非常干凈。類比一下Pipeline 像一條生產(chǎn)線Task 是線上不同工位Trigger 則是“什么時(shí)候開(kāi)工”的指令。你不需要為了定時(shí)任務(wù)單獨(dú)搭一臺(tái)機(jī)器也不需要為了 Webhook 在業(yè)務(wù)代碼里寫(xiě)接口全都在 YAML 里聲明出來(lái)。2.2 一個(gè)可以直接上手改的完整配置示例我不太喜歡引用那種只有三行、毫無(wú)參考價(jià)值的“hello world”示例下面這個(gè)配置是結(jié)合我自己項(xiàng)目的實(shí)際需求整理的。它覆蓋了依賴安裝、測(cè)試、失敗的郵件通知、晚上的自動(dòng)備份一個(gè)文件搞定。pipelines: main: title: 構(gòu)建并測(cè)試主分支 triggers: on_push: branch: main tasks: - name: install cmd: pip install -r requirements.txt -q - name: test cmd: pytest tests/ needs: [install] - name: report cmd: python scripts/notify.py --status {{ pipeline.status }} needs: [test] on_failure: true nightly: title: 每日備份與緩存清理 triggers: cron: 0 2 * * * tasks: - name: backup cmd: bash scripts/backup.sh - name: cleanup cmd: bash scripts/cleanup_cache.sh needs: [backup]注意看幾個(gè)關(guān)鍵點(diǎn)on_push.branch把觸發(fā)范圍限定在主干分支避免每個(gè)人推分支時(shí)都跑一遍needs聲明了任務(wù)間的順序on_failure: true表示即使前任務(wù)失敗也能發(fā)送報(bào)告。{{ pipeline.status }}是模板變量caveman 會(huì)把它替換成實(shí)際執(zhí)行狀態(tài)這是我后來(lái)在實(shí)踐里發(fā)現(xiàn)的實(shí)用小技巧。對(duì)于 Node.js 項(xiàng)目思路完全一致只是命令換成 npm。不要把 caveman 的配置理解成新的編排語(yǔ)言它本質(zhì)上就是把“你在服務(wù)器上手工會(huì)跑的命令”搬進(jìn) YAML然后加觸發(fā)條件和依賴關(guān)系。2.3 命令執(zhí)行背后的幾個(gè)關(guān)鍵細(xì)節(jié)關(guān)于每個(gè) task 中命令到底怎么跑這里有幾個(gè)容易踩坑的細(xì)節(jié)值得單獨(dú)說(shuō)。第一個(gè)細(xì)節(jié)是工作目錄。Caveman 默認(rèn)會(huì)在你的項(xiàng)目根目錄執(zhí)行命令但如果你把配置放在config/caveman.yaml項(xiàng)目根目錄怎么定義就要留意了。建議在項(xiàng)目根目錄放配置文件或者使用絕對(duì)路徑的腳本否則新手很容易遇到“命令明明存在但執(zhí)行時(shí)找不到文件”的詭異問(wèn)題。第二個(gè)細(xì)節(jié)是環(huán)境變量。Caveman 會(huì)繼承服務(wù)進(jìn)程的環(huán)境變量所以你在 systemd 或者 docker-compose 里定義的變量在任務(wù)里是能直接讀到的。但這同時(shí)也意味著你寫(xiě)在配置里的命令不應(yīng)該硬編碼任何密鑰。我的習(xí)慣是密鑰全部通過(guò)環(huán)境變量注入YAML 里只寫(xiě)變量名。第三個(gè)細(xì)節(jié)是退出碼。Caveman 判斷任務(wù)成不成功只看退出碼是不是 0。如果你在命令里寫(xiě)了多個(gè)子命令最好在關(guān)鍵步驟之間檢查退出碼比如python scripts/prepare.py pytest tests/這條命令中如果 prepare.py 失敗后面的 pytest 根本不會(huì)執(zhí)行整條命令退出碼也是非 0 的。這樣就能很自然地傳遞失敗狀態(tài)。反過(guò)來(lái)如果用了;連接命令即使前面失敗了后面還是會(huì)跑最后的退出碼取決于最后一條命令很容易掩蓋問(wèn)題。3. 實(shí)操?gòu)牧愦钇鹨粋€(gè)能用的 caveman 服務(wù)3.1 安裝和啟動(dòng)全流程記錄整個(gè)安裝過(guò)程比我想象中順利很多。在一臺(tái) Ubuntu 22.04 服務(wù)器上只需要確保 Python 3.10 以上可用然后執(zhí)行pip install caveman安裝完成后建議先寫(xiě)一個(gè)最簡(jiǎn)單的配置文件確認(rèn)服務(wù)能正常啟動(dòng)再逐步加內(nèi)容。啟動(dòng)服務(wù)有兩種常見(jiàn)方式前臺(tái)運(yùn)行方便看日志后臺(tái)運(yùn)行適合長(zhǎng)期使用。# 前臺(tái)運(yùn)行CtrlC 可退出 caveman serve --config .caveman.yaml # 后臺(tái)運(yùn)行日志寫(xiě)入文件 nohup caveman serve --config .caveman.yaml /var/log/caveman.log 21 正式部署我建議用 systemd 托管這樣開(kāi)機(jī)自啟和崩潰拉起都由系統(tǒng)負(fù)責(zé)。下面是一個(gè)最小可用的 service 文件[Unit] DescriptionCaveman CI service Afternetwork.target [Service] Userdeploy WorkingDirectory/home/deploy/myapp EnvironmentFile/home/deploy/.env ExecStart/usr/local/bin/caveman serve --config /home/deploy/myapp/.caveman.yaml Restartalways RestartSec5 [Install] WantedBymulti-user.target這里有個(gè)細(xì)節(jié)容易被忽略EnvironmentFile指定的文件里可以放各種環(huán)境變量caveman 的任務(wù)進(jìn)程會(huì)直接繼承。這樣你在 YAML 配置里就不會(huì)出現(xiàn)任何明文密鑰通知 Webhook 的 Token 也全都在環(huán)境文件里。首次啟動(dòng)后建議先檢查兩件事一是日志是否正常輸出二是服務(wù)監(jiān)聽(tīng)的端口是否能訪問(wèn)。默認(rèn)端口如果被占用可以通過(guò)參數(shù)調(diào)整但我是直接用本機(jī)回環(huán)地址加反向代理不額外暴露端口這樣更安全也更清爽。3.2 接入 Git 倉(cāng)庫(kù)的 Webhook 自動(dòng)觸發(fā)Caveman 的 Webhook 觸發(fā)機(jī)制很簡(jiǎn)單你在配置里聲明on_push觸發(fā)器它會(huì)在服務(wù)里開(kāi)一個(gè) HTTP 端點(diǎn)然后你在 Git 倉(cāng)庫(kù)后端配置一個(gè) Webhook把請(qǐng)求發(fā)到這個(gè)端點(diǎn)即可。以 Gitea 為例在倉(cāng)庫(kù)設(shè)置里添加 WebhookURL 填http://你的服務(wù)器地址:端口/ci/triggerContent Type 選 JSON觸發(fā)事件勾選 Push。保存后可以先手動(dòng)測(cè)試一次觀察 caveman 日志里是否收到請(qǐng)求。我遇到過(guò)的一個(gè)重要問(wèn)題是觸發(fā)安全。如果端點(diǎn)沒(méi)有校驗(yàn)別人知道你地址后可以偽造請(qǐng)求反復(fù)觸發(fā)構(gòu)建既不安全也浪費(fèi)資源。所以在生產(chǎn)環(huán)境必須打開(kāi) token 校驗(yàn)caveman 通常支持在觸發(fā)端點(diǎn)要求攜帶固定參數(shù)配置大致如下triggers: on_push: branch: main token: ${CAVEMAN_WEBHOOK_TOKEN}這里的${CAVEMAN_WEBHOOK_TOKEN}會(huì)被解析成環(huán)境變量值。Git 倉(cāng)庫(kù)端 Webhook 配置里添加一個(gè)請(qǐng)求頭或參數(shù)把同樣的 Token 帶上caveman 校驗(yàn)通過(guò)才會(huì)真正觸發(fā)任務(wù)。為了驗(yàn)證鏈路是否通暢可以先用 curl 模擬一次curl -X POST http://127.0.0.1:5000/ci/trigger \ -H Content-Type: application/json \ -H X-Caveman-Token: your-token \ -d {ref: refs/heads/main}如果日志里出現(xiàn)“trigger accepted”之類的信息說(shuō)明 Webhook 鏈路已經(jīng)打通。這里有一個(gè)排錯(cuò)技巧很多團(tuán)隊(duì)發(fā)現(xiàn) Webhook 不觸發(fā)問(wèn)題往往不在 caveman而在 Git 平臺(tái)默認(rèn)不給localhost或內(nèi)網(wǎng) IP 發(fā)請(qǐng)求需要在平臺(tái)設(shè)置里允許內(nèi)部或自定義網(wǎng)絡(luò)地址。3.3 把執(zhí)行結(jié)果通知到人自動(dòng)化的最后一步是讓正確的人在正確的時(shí)間知道結(jié)果。Caveman 本身把“執(zhí)行任務(wù)”和“上報(bào)結(jié)果”都當(dāng)成普通任務(wù)處理所以你完全可以在一個(gè) pipeline 的最后掛一個(gè)通知任務(wù)用一段腳本把結(jié)果推到辦公協(xié)作軟件里。我自己的做法是寫(xiě)一個(gè)可以復(fù)用的通知腳本核心邏輯就是拼接文本再通過(guò) Webhook 發(fā)出去。它接收兩個(gè)參數(shù)任務(wù)名和狀態(tài)其他信息從環(huán)境變量讀。#!/usr/bin/env bash # scripts/notify.sh set -euo pipefail TASK_NAME${1:-unknown} TASK_STATUS${2:-unknown} PROJECT_NAME${PROJECT_NAME:-my-project} WEBHOOK_URL${NOTIFY_WEBHOOK_URL:-} if [ -z ${WEBHOOK_URL} ]; then echo [notify] no webhook url, skip exit 0 fi curl -s -X POST ${WEBHOOK_URL} \ -H Content-Type: application/json \ -d { \msg_type\: \text\, \text\: { \content\: \[Caveman] ${PROJECT_NAME} ${TASK_NAME} ${TASK_STATUS}\ } }在 YAML 里調(diào)用時(shí)建議用on_failure和on_success這類鉤子做區(qū)分。比如- name: notify cmd: bash scripts/notify.sh test failed on_failure: true needs: [test]這里的關(guān)鍵原則是通知腳本本身不能影響構(gòu)建結(jié)果。哪怕通知發(fā)送失敗也不應(yīng)該讓整個(gè) pipeline 顯示為失敗。所以腳本里如果通知環(huán)節(jié)出錯(cuò)要么用|| true要么在腳本內(nèi)部捕獲異常并返回 0。我把這個(gè)教訓(xùn)寫(xiě)進(jìn)這里也是因?yàn)樵?jīng)踩過(guò)一次通知接口超時(shí)導(dǎo)致整個(gè)構(gòu)建被標(biāo)記為失敗而真正的測(cè)試其實(shí)是全部通過(guò)的。3.4 跑定時(shí)任務(wù)時(shí)的常見(jiàn)習(xí)慣定時(shí)任務(wù)是 Caveman 很常用的能力比如每天凌晨備份數(shù)據(jù)庫(kù)、每周清理構(gòu)建緩存、定期跑一次完整的回歸測(cè)試。定時(shí)配置寫(xiě)在 pipeline 的triggers.cron里采用標(biāo)準(zhǔn)的 cron 表達(dá)式。pipelines: weekly_cleanup: triggers: cron: 0 4 * * 1 tasks: - name: cleanup cmd: bash scripts/cleanup_docker_cache.sh關(guān)于 cron 我有兩個(gè)建議第一盡量避開(kāi)業(yè)務(wù)高峰時(shí)段凌晨三四點(diǎn)通常是很好的選擇第二任務(wù)執(zhí)行時(shí)間如果可能超過(guò)間隔需要自行維護(hù)一個(gè)狀態(tài)文件避免同一個(gè)任務(wù)還沒(méi)跑完又啟動(dòng)另一輪。Caveman 似乎不會(huì)自動(dòng)處理重疊執(zhí)行這是個(gè)需要注意的邊界問(wèn)題。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 任務(wù)一直排隊(duì)不執(zhí)行這個(gè)現(xiàn)象我遇到不止一次最典型的場(chǎng)景是服務(wù)正常啟動(dòng)Webhook 也觸發(fā)了但任務(wù)狀態(tài)一直是 pending遲遲沒(méi)有轉(zhuǎn)成 running。排查思路固定順序先看 worker 狀態(tài)。Caveman 的服務(wù)進(jìn)程里調(diào)度器和執(zhí)行器是配合工作的執(zhí)行器其實(shí)就是一組 worker。如果 worker 數(shù)量設(shè)置為 0或者啟動(dòng)異常任務(wù)就會(huì)永遠(yuǎn)排隊(duì)。可以這樣確認(rèn)caveman status如果顯示沒(méi)有活躍 worker基本可以確定問(wèn)題方向。此時(shí)檢查服務(wù)日志看 worker 初始化時(shí)是否報(bào)錯(cuò)。比如某些環(huán)境缺少必要的執(zhí)行依賴或者工作目錄沒(méi)有寫(xiě)權(quán)限都會(huì)導(dǎo)致 worker 起不來(lái)。另外如果任務(wù)本身設(shè)置了并發(fā)限制例如同一時(shí)間只允許一個(gè)實(shí)例運(yùn)行那么上一個(gè)任務(wù)如果因?yàn)槟承┰驔](méi)有正常結(jié)束后續(xù)任務(wù)就會(huì)一直排隊(duì)。解決辦法是手動(dòng)清理舊的運(yùn)行狀態(tài)或者調(diào)整并發(fā)參數(shù)。4.2 構(gòu)建日志為空但任務(wù)失敗另一個(gè)常見(jiàn)困惑是任務(wù)明明失敗了可點(diǎn)開(kāi)日志卻沒(méi)看到任何有效內(nèi)容。這個(gè)問(wèn)題大多出在命令輸出沒(méi)有被正確捕獲上而不是任務(wù)真的沒(méi)有執(zhí)行。我遇到過(guò)兩次這種情況。第一次是因?yàn)槟_本里有一條命令調(diào)用了nohup把子進(jìn)程放到后臺(tái)導(dǎo)致 caveman 認(rèn)為主命令已經(jīng)結(jié)束但實(shí)際工作還在繼續(xù)。第二次是腳本中使用了交互式命令進(jìn)程等待標(biāo)準(zhǔn)輸入直到超時(shí)被系統(tǒng)殺掉日志自然只有一行超時(shí)記錄。給個(gè)排查建議在任何復(fù)雜腳本開(kāi)頭加一行echo start at $(date)在結(jié)尾加一行echo end at $(date)就能快速定位是沒(méi)執(zhí)行、沒(méi)輸出還是卡住超時(shí)。這個(gè)習(xí)慣成本極低但排查效率提升非常明顯。4.3 在容器環(huán)境中有權(quán)限問(wèn)題如果你希望任務(wù)跑在 Docker 容器里比如在一個(gè)固定鏡像中編譯項(xiàng)目那么權(quán)限問(wèn)題是繞不開(kāi)的。最常見(jiàn)的是 socket 權(quán)限錯(cuò)誤Got permission denied while trying to connect to the Docker daemon socket常規(guī)解法是把運(yùn)行 caveman 的用戶加入 docker 用戶組sudo usermod -aG docker deploy改完用戶組以后必須重新登錄會(huì)話才能生效。如果你通過(guò) systemd 啟動(dòng)服務(wù)在添加到 docker 組后要再執(zhí)行sudo systemctl restart caveman讓服務(wù)進(jìn)程重新獲得新的權(quán)限組。但這引出一個(gè)安全方面的思考如果任務(wù)會(huì)執(zhí)行任意代碼那么這些代碼其實(shí)是以運(yùn)行用戶權(quán)限跑的。給用戶 docker 權(quán)限等同于給了最高系統(tǒng)權(quán)限。所以我后來(lái)更推薦在配置層面明確區(qū)分哪些任務(wù)需要容器環(huán)境哪些任務(wù)直接本機(jī)執(zhí)行容器命令只放在獨(dú)立 pipeline 中并且嚴(yán)格限制可訪問(wèn)的倉(cāng)庫(kù)。4.4 Webhook 常見(jiàn)三連坑Webhook 不觸發(fā)、重復(fù)觸發(fā)、觸發(fā)時(shí)機(jī)不對(duì)這三個(gè)問(wèn)題幾乎每家都會(huì)踩到。不觸發(fā)先確認(rèn)端點(diǎn)和 token 是否正確再確認(rèn) Git 平臺(tái)是否有防火墻規(guī)則攔截內(nèi)網(wǎng)或自定義端口請(qǐng)求。某些托管平臺(tái)默認(rèn)禁止 Webhook 發(fā)送到非標(biāo)準(zhǔn)端口這時(shí)候需要在平臺(tái)側(cè)放行。重復(fù)觸發(fā)很多 Git 平臺(tái)在推送 tag、編輯 PR、同步 mirror 等不同場(chǎng)景下都會(huì)發(fā)不同事件。配置里應(yīng)該按需聲明事件類型并通過(guò)分支名過(guò)濾避免一個(gè)簡(jiǎn)單 push 變成四五次構(gòu)建。觸發(fā)時(shí)機(jī)不對(duì)比如計(jì)劃在 merge request 通過(guò)后再構(gòu)建而不是每次 push 都構(gòu)建。這類需求請(qǐng)?jiān)谂渲美锸褂脤?duì)應(yīng)的事件類型和判斷條件不要指望“回調(diào)之后過(guò)濾”。Caveman 的觸發(fā)配置能完成大部分常見(jiàn)場(chǎng)景但如果你需要的是一門(mén)極其精細(xì)的判斷邏輯直接在任務(wù)里寫(xiě)一段 Shell 判斷往往更直接可控。4.5 環(huán)境變量管理不當(dāng)導(dǎo)致泄露最后提醒一個(gè)很少人提但非常重要的問(wèn)題YAML 配置本身可能被項(xiàng)目成員查看所以不要在里面寫(xiě)死 Token、密碼、密鑰。哪怕倉(cāng)庫(kù)是私有的也要當(dāng)它遲早會(huì)泄露來(lái)管理。一個(gè)穩(wěn)妥的習(xí)慣是配置里只寫(xiě)${VAR_NAME}變量值統(tǒng)一放在運(yùn)行服務(wù)的機(jī)器的環(huán)境文件里。配合 systemd 的EnvironmentFile使用既方便在不同環(huán)境部署也避免密鑰進(jìn)入版本歷史。如果你需要為不同項(xiàng)目提供不同環(huán)境變量我建議不要共用一個(gè)環(huán)境文件而是以項(xiàng)目名為前綴隔離例如MYAPP_DB_PASSWORD、MYAPP_NOTIFY_TOKEN。這樣一個(gè)腳本出問(wèn)題不會(huì)影響其他項(xiàng)目排查范圍也小得多。最后分享一點(diǎn)個(gè)人體會(huì)回頭看我為什么會(huì)堅(jiān)持用 caveman 這類極簡(jiǎn) CI 方案而不是一直躺在 Jenkins 的舒適區(qū)里本質(zhì)原因其實(shí)是心智負(fù)擔(dān)。重工具的每一個(gè)插件、每一條流水線配置、每一次版本升級(jí)都在不斷消耗你的注意力而最終換來(lái)的能力在小團(tuán)隊(duì)里絕大部分根本用不上。我在實(shí)際操作中的體會(huì)是把 CI 做到最簡(jiǎn)反而更能逼著團(tuán)隊(duì)把構(gòu)建腳本本身寫(xiě)好。沒(méi)有圖形界面幫你隱藏過(guò)程沒(méi)有神秘動(dòng)作幫你收拾爛攤子一切都要靠 Shell 腳本和清晰的依賴關(guān)系兜底這恰好是工程能力最能沉淀的地方。如果你也想嘗試我建議先從一個(gè)小項(xiàng)目開(kāi)始一個(gè)倉(cāng)庫(kù)、一個(gè) YAML、三個(gè)任務(wù)。把構(gòu)建、測(cè)試、通知跑通運(yùn)轉(zhuǎn)一兩周以后再慢慢加定時(shí)任務(wù)和容器步驟。等有一天你會(huì)發(fā)現(xiàn)你已經(jīng)完全不關(guān)心 CI 平臺(tái)本身用的是什么因?yàn)榕渲酶鴤}(cāng)庫(kù)走、命令就是終端命令換哪臺(tái)服務(wù)器都能立刻跑起來(lái)這種感覺(jué)確實(shí)比想象中的還要舒服。