起點是一個很具體的問題：

出了一個 CVE，我要在幾分鐘內回答「本行哪些系統在用這個套件、哪一版、部署到哪」。

有 SBOM 不等於答得出來。我花了兩天把一條完整的鏈接起來—— pipeline 產成品 → 算 digest → SCA 掃描（Mend SaaS）→ 依賴樹入帳 → 用 PURL 反查—— 每一步都跑成功。然後逐條驗，四件事是錯的。其中兩件是我自己算錯的，那兩件反而更值得寫。

一、能寫、能讀，就是不能查

要回答「誰在用」，前提是成品身分（image digest）要能綁在掃描紀錄上。 Mend 支援 project tag，於是我掃描時帶上：

mend dep --update --tags artifactDigest:<sha256>

（順帶一提，分隔符是 : 不是 =，而且 --tags 與 --local 互斥—— 要打標籤就必須上傳，純本機掃描拿不到標籤。）

寫入成功。讀回來也成功：

[{"key": "artifactDigest", "value": "50cd47b9…"}]

到這裡我差點就寫「可行」。幸好多做了一步——拿一個不存在的值去查：

四個一模一樣，連語法錯誤都不報錯。

（測的是 Platform API v2.0 GET /orgs/{org}/projects 的 tag／tags 參數，2026-08 實測。 不排除另有查詢途徑，但至少不是最明顯的那一條。）

這不是「查不到」，是根本沒在查——參數被整個忽略了。 只測真實值那一次，會百分之百誤判成成功，因為它確實回了一堆資料。

教訓：任何「可以用 X 查詢」的宣稱，驗收方式不是「用真的 X 查一次看有沒有結果」， 是用一個保證不存在的 X 查一次，看結果有沒有變。沒變就是假的。

對這個案子的結論很硬：tag 是註記，不是鍵。 digest 寫得進去、看得到，但沒辦法拿它反查，那它就只是個顯示欄位。

二、direct 和 transitive，我用錯規則分了一遍

帳本要分「直接相依」和「被別人帶進來的」，因為兩者的處置完全不同： 直接相依你改得動 manifest，遞移相依你只能等上游或換套件。

我自己寫的判斷規則是：在依賴樹裡曾經當過別人的 parent，就算遞移。 跑出來 direct 28、transitive 23。

同一個專案，Mend API 給的答案是 direct 2、transitive 49。

差了一個數量級。錯的是我：direct 的定義不是「在樹的哪一層」， 是「有沒有寫在 manifest 的頂層宣告裡」。 一個套件可以同時是頂層宣告、又是別人的 parent，我的規則把它判成遞移。

教訓：同一件事有兩個來源時，先對帳再相信自己算的那個。 我如果沒去拉 API 交叉比對，這個數字會一路帶到報表上，而且看起來完全合理。

三、誠實欄位算錯，比沒有誠實欄位更糟

我在全量匯出的 metadata 裡放了幾個「這份資料自己的品質」欄位， 本意是不要讓人以為涵蓋率 100%：

artifacts=36  artifactsWithoutDigest=6  artifactsWithoutDepGraph=28

第一版跑出來是 artifactsWithoutDepGraph=36——36 之 36，全部都沒有依賴圖。

但我明明親手把 80 條依賴邊灌進去過。去看程式碼，錯在我拿成品的 artifact_id 去比對一個裝 PURL 的集合——兩種東西永遠比不中，所以答案恆等於「全部都沒有」。

這個 bug 的性質值得說清楚：它不會讓資料變少，它會讓一個宣稱自己誠實的欄位說謊。 而且方向是「把自己講得更爛」，所以看起來像是保守、不像是錯——最不容易被抓的那種。

教訓：誠實欄位本身也要測。 一個沒被測試過的品質指標，跟沒有品質指標是兩回事——後者只是缺，前者是錯誤資訊。

四、build_ref 是空的，而且空在最該有的地方

帳本每一筆成品都記來源：intake（A=pipeline 自動、B=工具匯入、C=人工填）， 以及 build_ref（哪一次 build、哪個 commit）。

我抽查時發現，有幾筆 intake=A 的紀錄，build_ref 是空字串。

intake=A 的意思是「這筆是 pipeline 自動入帳的，信心最高」。 而 build_ref 空，代表這筆最可信的紀錄，追不回是哪次 build、哪個 commit 產生的。 七段稽核鏈（成品 → 品質關卡 → 建置來源 → 原始碼）就斷在這裡。

更麻煩的是它不會報錯。信心等級照樣算成 high，因為我當初的規則是 「intake=A 且有 digest → high」——沒有把 build_ref 算進去。

教訓：信心等級不能是「填進來的」，必須是從實際欄位推導出來的； 而推導規則要涵蓋所有讓它不可信的欄位，漏一個就會出現「高信心的斷鏈」。

那怎麼驗才有用

這四條抽出來是四個可以直接套用的動作：

共同點是一樣的：成功的那次不構成證據，失敗的那次才構成證據。 一個永遠回傳結果的查詢，跟一個真的在過濾的查詢，長得一模一樣—— 除非你去問它一個它應該答不出來的問題。

本文所有數字來自我自己建的示範專案（一個 Vue 前端 + 一條 Azure Pipelines）， 在筆電與雲端 CI 上都可重現。表一的 N 是同一個實際數字，與結論無關故略。 工具版本以 2026 年 8 月實測為準，廠商日後修正不在本文追蹤範圍。

我在筆電的 CRC 上把 Open Data Hub 3.5 裝起來（它是 OpenShift AI 的上游開源版，元件同源），用 KServe 把一顆自己從零訓練的小 GPT 上線，再開 Data Science Pipelines 跑一條訓練流程。全程綠燈。

然後我開始逐條驗證。以下四件事都是綠燈狀態下的錯誤。

一、pod 要到 GPU，不代表模型算在 GPU 上

這是四件裡最貴的。

幾乎所有推論服務都有這樣一行，這是標準寫法不是壞程式：

device = "cuda" if torch.cuda.is_available() else "cpu"

CUDA 掛不上時——驅動沒裝、容器沒掛 nvidia runtime、torch 裝成 CPU wheel、CUDA_VISIBLE_DEVICES 被清空——這行不報錯、不警告，安靜退回 CPU。服務照常啟動、readiness probe 照常變綠、推論照常回應。

而在 Kubernetes 這一層，pod 的 resources.limits["nvidia.com/gpu"]: 1 照樣成立，那張卡照樣被這個 pod 佔住不給別人用。於是你同時得到「GPU 被消耗」和「GPU 沒被使用」。

我做了一組對照：同一份程式碼、同一個 venv、同一個 torch（cu128 build）、同一顆模型、同一個 prompt。B 組唯一的改動是 CUDA_VISIBLE_DEVICES="" ——這正是「容器沒把卡掛進來」在應用層的效果。兩組分開跑，先確認閒置時 GPU 是乾淨的。

只有最後一條分得出來：

nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

它問的是「哪個進程真的在這張卡上配了記憶體」，而這是應用程式無法自報、也不容易造假的。在叢集上就是：

oc debug node/<gpu-node> -- chroot /host nvidia-smi \
   --query-compute-apps=pid,process_name,used_memory --format=csv

要在送出推論請求前後各跑一次。 沒有對照，不算證據。

兩個會讓你自己騙自己的陷阱：

1. 延遲比不是固定的。我這顆模型只有 8M 參數，GPU 只快 2.5 倍（模型太小，kernel launch 和資料搬運吃掉大半好處）。7B 級的模型應該是 10–50 倍。反過來說，小模型「沒快多少」不能證明沒用到 GPU。
2. 顯存佔用小不代表沒用到。A 組只吃 228 MiB、使用率峰值 30%。判準是「有沒有出現在 compute-apps」，不是數字大不大。

二、imageID 不反映 image 從哪裡拉來

離線環境的核心問題是：叢集裡的每顆 image 都必須來自你的私有 registry。

直覺的驗法是列出所有 pod 的 imageID 看有沒有外部位址。我原本也是這樣寫檢查腳本的，直到我真的把一顆 image 鏡像進私有 registry、設好 ImageDigestMirrorSet、確認 pod 從私有 registry 起來了——然後查 imageID：

quay.io/opendatahub/odh-workbench-jupyter-datascience-cpu-py312-ubi9@sha256:6f0e6268…

還是 quay.io。 但它確實是從私有 registry 拉的，證據有三件：Harbor 的 pull_count 增加了、節點的 registries.conf 裡那個來源標著 blocked = true、pod 正常 Running。原站被封鎖而 pod 起得來，只可能來自鏡像端。

原因很簡單但容易忽略：imageID 回報的是 image 的身份（來源名稱 ＋ digest），IDMS 改的是去哪裡拿，不改這是誰。

所以這一條要拆成兩個不同的問題：

順帶一提第一個問題的答案很有意思：在一個 DataScienceCluster 顯示 Ready、dashboard 全綠的叢集上，正在跑的 pod 用了 60 顆外部 image，光元件本身就 23 顆。而 operator bundle 的 relatedImages 只列了 5 顆。只照 bundle 做鏡像，會裝到一半斷。

最容易漏的是 sidecar：odh-kube-rbac-proxy 被注入到每個 InferenceService 的 pod 裡，不在任何「元件清單」上，但少了它模型就上不了線。

三、鏡像設定的預設值，會讓離線測試「假成功」

ImageDigestMirrorSet 有一個欄位叫 mirrorSourcePolicy，預設是 AllowContactingSource：

如果你在還有對外連線的環境測試離線設定——這是常態，因為要先驗過才敢斷網——用預設值會得到「看起來成功」的結果，實際上走的是外網。真正斷網後才失敗。

節點端對應的實作就是 registries.conf 裡的 blocked = true。驗收時要看到這個字。

還有一個相關的坑：IDMS 靠 digest 比對，所以鏡像過程必須保留原始 digest（skopeo copy --preserve-digests）。若映像被重新打包導致 digest 改變，IDMS 會靜默失效，症狀是叢集仍往外網拉，而錯誤訊息不會指向真正原因。

更麻煩的是：IDMS 只管 digest 拉取（節點設定是 pull-from-mirror = "digest-only"）。但 pipeline 執行期產生的 pod 是用 tag 拉的：

init=quay.io/opendatahub/ds-pipelines-argo-argoexec:3.6.12

tag，不是 digest。IDMS 完全管不到，要另外設 ImageTagMirrorSet。官方離線文件主推 IDMS（因為安裝階段的 image 都釘 digest），但執行期不是。這是「照官方文件做完，離線仍然不通」的典型缺口。

而且這幾顆 image（argoexec、driver、launcher）是跑第一條 pipeline 才會被拉的——安裝完成後做任何盤點都不會出現它們。跑過一次 pipeline 後，全叢集去重 image 從 65 顆變成 93 顆。

結論：image 盤點必須在「跑過一次完整 pipeline 之後」再做一次。

四、內建資料庫是 latin1，中文一個字都存不進去

這條特別適合台灣的環境。

上傳一條 pipeline 直接 HTTP 500，介面上只顯示「Internal Server Error」。翻後端 log 才看到真因：

Error 1366 (22007): Incorrect string value: '\xE5\xAE\x8C\xE6\x88\x90...'
  for column `mlpipeline`.`pipeline_versions`.`PipelineSpec`

\xE5\xAE\x8C\xE6\x88\x90 是「完成」兩個字。內建 MariaDB 的 database 預設是 latin1_swedish_ci。

影響範圍比第一眼大：不只 pipeline 本體，中繼資料的 Artifact／Execution／Context 表也全是 latin1——代表執行期間只要產生任何中文中繼資料就會失敗。

修法要注意表級 CONVERT TO CHARACTER SET 會被外鍵擋（Error 1832），得逐欄位轉並跳過外鍵欄位：

ALTER TABLE `<table>` MODIFY `<col>` <type>
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

我這邊轉了 67 個文字欄位，剩下 8 個是 UUID 欄位不需要中文。轉完就上傳成功。

為什麼這條值得寫進驗收條件：用英文測永遠不會踩到。這是 demo 抓不到、上線才爆的典型。

那怎麼驗才有用

四件事的共同點是：它們在所有會給你看的畫面上，都跟正確狀態長得一模一樣。

歸納下來，有用的驗收條件有三個特徵：

1. 問「證據」不問「狀態」。「GPU 有配給嗎」是狀態，「哪個進程在卡上配了記憶體」是證據。
2. 要求對照，不接受單點。送請求前後各查一次、GPU 與 CPU 各跑一次、封鎖原站再拉一次。單一數字沒有意義。
3. 明確寫出「不接受什麼」。這比寫「要求什麼」有用得多——因為對方交來的東西通常都能滿足「要求什麼」。

最後一個心得跟技術無關：我原本用覆蓋率當進度指標（清單裡幾條驗過了），後來發現那是錯的指標。lab 裡永遠驗不到 GPU 硬體、驗不到 75 GB 的鏡像量級，而那恰好是真實環境裡最貴的部分。覆蓋率衝高只會製造「準備好了」的錯覺。

換成「這條沒驗，現場我會不會被唬過去」來排序之後，做的事情完全不一樣了。

文中所有數字皆為單機 lab 實測（CRC + Open Data Hub 3.5 + KServe RawDeployment，GPU 部分為 RTX 5070 Laptop）。

今年六月起我從零手刻了一個 decoder-only GPT，一路推完資料工程、現代架構、訓練評估、服務化、 治理、漂移重訓、到後訓練對齊（SFT → DPO/IPO → GRPO/PPO），寫成一本 Quarto 線上書：

https://ryangtr.github.io/llm-from-scratch/（原始碼：ryanGTR/llm-from-scratch，MIT，CI 綠）

它跟這裡的其他文章是同一個站底下的另一個 repo，所以不會出現在首頁列表。補一篇當入口。

為什麼一個做交付鏈的人去刻 GPT

因為 LLM 對我一直是黑盒，而黑盒沒辦法治理。與其追工具，我決定把一個 GPT 從零養大， 再用我熟的那套——digest 身份、promotion gate、lineage、可觀測——把它管起來。 兩塊的交集（MLOps ＋ 模型治理）正是我想站的位置。

模型刻意小：demo 0.8M、中文實戰 8M、char-level。小到一次對照實驗幾十秒到幾分鐘， 所以我能做很多次「先預測 → 實測 → 被打臉 → 想懂為什麼」。這本書的價值在那些打臉，不在模型。

四次被打臉

1. 聚合指標說健康，資料裡有 21.6% 是髒的。 換成 105 MB 中文維基後，熵、壓縮比、重複率全部 ✅。我不信，寫了一套偵測器逐條掃， 抓到 21.6% 的文件殘留維基繁簡轉換語法 -{zh-tw:..;zh-cn:..}-。修一條清洗規則 → 0.05%。 這跟疊稽核控制項是同一個動作：看樣本發現問題 → 寫成一條偵測器 → 累積成資料的測試套件。

2. 同一顆模型，換把尺，結論相反。 SFT 做完用維基 perplexity 量，顯示「變爛了」。那是預訓練的尺，量後訓練必然誤判（alignment tax）。 改量「只算回答段的 loss」，還是 base 贏——因為 gold 答案是維基句，base 預訓練時背過。 最後量「生成是否以定義句應答」這個行為：base 29% → SFT 72%。尺選錯，數字再漂亮也是錯的。

3. train-acc 100% 不代表學會。 DPO 兩種偏好軸，train-acc 都在第 200 步衝到 100%。held-out 一個 97%、一個 9%。 前者學到可遷移的特徵，後者是把 784 組訓練對背起來。只看 train 會宣稱兩個都學會了。

4. reward model 給高分，不代表答案好。 RLHF 拿掉 KL 錨、讓 RL 用力最大化 reward model：分數從 3.7 衝到 13.2， 輸出卻 collapse 成「不管問什麼都吐同一串垃圾」，多樣性 100% → 6%。那串垃圾落在 reward model 的訓練分布外、被誤判高分。 這是 Goodhart’s law 的活體——指標一旦變成目標就不再是好指標。跟 KPI 被衝爆是同一件事，防法是 KL 錨把 policy 綁在可信的舊模型附近。

交付鏈的東西原封不動搬過去

書的第 7 章「模型治理：把稽核接到 ML」就是這張表展開來。

怎麼讀、怎麼跑

不用 GPU 也能重現每一章的結論。book/examples/tiny_*.py 每支都是純 CPU、只要 torch、幾十秒到幾分鐘，CI 顧著不會壞：

git clone https://github.com/ryanGTR/llm-from-scratch && cd llm-from-scratch/book/examples
curl -o input.txt https://raw.githubusercontent.com/karpathy/char-rnn/master/data/tinyshakespeare/input.txt
python tiny_gpt.py      # 幾分鐘訓出一個會「假裝莎士比亞」的小模型（GPU 上 35 秒）
python tiny_dpo.py      # 親眼看 train-acc 100%、held-out 才說真話
python tiny_serve.py    # digest 身份 ＋ promotion gate 真的擋下

誠實的邊界

這不是 ChatGPT。8M 參數、char-level、單機——它學會中文的字、詞、語法、標點，寫不出連貫文章。 能力上限受限於規模，這我從第一頁就講清楚。價值在走完整條鏈時的工程判斷： 可重現（uv lock）、可驗證（單元測試 ＋ 驗收 playbook ＋ CI）、可觀測、可治理—— 以及那條貫穿全書的紀律：永遠先問這把尺量到什麼、有沒有被汙染。

企業裡的交付鏈通常是這樣的：開發者在 Jenkins 按「帶參數建置」，填一個變更單號；Jenkins 丟給 OpenShift 上的 Tekton； Tekton 跑十來個 task 把 image 推進 Harbor；最後改一個 GitOps repo，等 OP 在 Argo 按 Sync。

問題是，用的人看不到中間。Jenkins 綠了就當成功，出事不知道先看哪，image 有三個 tag 不知道是不是同一顆。 而生產環境不能讓你按壞。

所以我把它搬到筆電上。同樣的參數名、同樣的 task 順序、同樣的 Harbor 待審區與手動 replication、同樣「Argo 不自動 sync」。 差別只有一個：按壞了 make up 重來。

長什麼樣

一次 build：

gate → setup → test → dockerfile-lint → build → deploy → health → tag-release → img-release → img-scan → helm-release → gitops

gate 是加的：變更單號格式不對（不是 CRQ + 12 碼）就整條不跑。其他十一個照上游。

三個驗收題

這個 lab 的設計目標就是讓用的人能回答這三題：

1. 從 Jenkins 按一次 build，在 OCP console 找到 PipelineRun，說出它卡在哪個 task。
2. 在 Harbor 找到剛建的 image，說出它有幾個 tag、為什麼 digest 一樣。
3. 說出「Jenkins 綠了但沒上線」要先看哪三個地方。

第三題的答案牽涉 --showlog 假綠， 第二題牽涉放行流程：pipeline 只能把 image 放到 demo-tmp，管理員手動觸發 replication 搬進 demo， 結果是三個 tag（git sha、時間戳、變更單號）、一個 digest。放行換的是名字，不是內容。

怎麼跑

git clone https://github.com/ryanGTR/ocp-pipeline-lab && cd ocp-pipeline-lab
make preflight                  # 缺什麼、怎麼補
cp lab.env.example lab.env
make up                         # gitea → harbor → ocp → jenkins → check
make build                      # Jenkins 觸發一次，等 Tekton 12/12
make build PUNCH=CRQ123         # 故意填錯
make promote SRC=<git sha> PUNCH=CRQ000000000200

有 CRC 的人大約十五分鐘看到第一條綠的；從零開始約一小時，多數時間在等 CRC 啟動與拉 image。 每支 script 都可以重跑。

踩過的坑

做這個 lab 撞了二十一個坑，每個都會讓人多花半天：rootless Harbor 的 log service、JCasC 的 readFileFromWorkspace、 容器裡解不到 api.crc.testing、toolkit 的 registry 啟發式、buildah 的 privileged…… 全部在 repo 的 docs/pitfalls.md，每條附解法。

它不是什麼

• 不是生產架構。HTTP 的 Harbor、寫在 lab.env 的密碼、insecure-skip-tls-verify——全是為了在筆電上十五分鐘跑起來。
• 沒有 Argo CD。lab 到「gitops repo 有新 commit」為止，因為重點是 pipeline 這一段；Argo 那一段在真實環境是 OP 按 Sync。
• 不含任何特定組織的設定。task 名字、namespace、參數名都是通用的。

repo：github.com/ryanGTR/ocp-pipeline-lab

用 IBM Cloud-Native Toolkit（v2.7.7）的 ibm-build-tag-push 跑 build， PipelineRun 停在 build，狀態 PodAdmissionFailed：

pods "node-pipeline-run-xxxxx-build-pod" is forbidden: unable to validate against any security context constraint:
  provider "pipelines-scc": .containers[0].privileged: Invalid value: true: Privileged containers are not allowed

看 task 的定義就知道為什麼：

- name: build
  image: quay.io/buildah/stable:v1.15.0
  securityContext:
    privileged: true

上游 v2.7.7 裡 privileged: true 的 task：build-tag-push、image-release、img-scan（trivy）、img-scan-trivy、operator-*、build-tag-push-ace-bar。 前三個就在一條標準 pipeline 的路徑上。

為什麼上游這樣寫

buildah 在容器裡建 image 要做幾件平常容器不給做的事：建 user namespace、掛 overlay、設 file capabilities。 最省事的解法是 privileged: true，一次拿到全部。2020 年左右的 toolkit 就這樣寫了，一直沒改。

在 OpenShift 上這件事由 SCC（Security Context Constraints） 管。 OpenShift Pipelines operator 給 pipeline 的 SA 綁的是 pipelines-scc——它允許的比 restricted 多，但不含 privileged。 要跑 privileged 得平台管理員另外綁 privileged SCC 給那個 SA，等於把整個 pipeline namespace 的 build 都開成 root 等級。

實際需要的只有兩樣

- name: build
  image: quay.io/buildah/stable:v1.15.0
  securityContext:
    capabilities:
      add: [SETFCAP]
  env:
    - name: STORAGE_DRIVER
      value: vfs

• SETFCAP：buildah 解開 base image 時要把 file capabilities（例如 ping 的 cap_net_raw）寫回檔案。沒有這個 capability 會在解 layer 時出錯。pipelines-scc 允許加 SETFCAP。
• STORAGE_DRIVER=vfs：overlay 在非 privileged 容器裡需要 fuse-overlayfs 或 kernel 支援 unprivileged overlay，兩者在 pod 裡都不保證有。vfs 用純複製，慢但一定能跑。

改完以後 pod 的 annotation 是 openshift.io/scc: pipelines-scc，build 正常推進 Harbor。 lab 裡一個 22 MB 的 demo app，build 加 push 約 5 分鐘——vfs 的代價很明顯，每一層都是整份複製。教學 lab 可以接受；真要快就得談 fuse-overlayfs 或 kernel 的 unprivileged overlay。

skopeo 根本不需要

image-release 和 img-scan 的 skopeo step 也標了 privileged: true。 skopeo 只是 registry 到 registry 的複製，不建 image、不掛任何東西。把 securityContext 整段拿掉，照跑。

猜測是當初複製貼上 build task 的模板留下來的。這類「沿襲下來的 privileged」在老 task 庫裡很常見，值得逐一檢查。

一個相關的坑：toolkit 的 registry 啟發式

同一批 task 裡還有一段：registry host 含 :（有 port）就判定為 OpenShift 內建 registry，不帶帳密。 lab 的 Harbor 跑在 host:8088，結果 skopeo 匿名去拉 private project，unauthorized。 生產環境的 Harbor 通常走 443 沒有 port，不會中；lab 或任何非標準 port 的 registry 就會。 這段判斷在 lab 的 shim 裡直接拿掉了。

在 lab 裡看

ocp-pipeline-lab 的 tekton/tasks/lab-build-tag-push.yaml 是改過的版本， NOTICE 列了相對上游的每一項改動。想重現原始錯誤：把 capabilities 換回 privileged: true，make build，看 PodAdmissionFailed。

Jenkins 的 job 長這樣，很多地方都這麼寫：

stage('Trigger Tekton') {
  steps {
    sh 'tkn pipeline start node-pipeline -n tpipeline -s pipeline --showlog \
          -p git-url=$csp_git -p git-revision=$git_revision ...'
  }
}

Tekton 那邊 build 這一格紅了（推 image 失敗），Jenkins 的 build SUCCESS。 Console Output 裡其實看得到錯誤訊息，但沒人會去看綠色 build 的 log。

我在 lab 裡重現它只花了一次：把 Harbor 的 TLS 設定弄錯，Tekton 的 build task 在 buildah login 就死了， Jenkins 照樣綠。

原因

tkn pipeline start --showlog 做兩件事：建 PipelineRun，然後跟著串 log。 它的 exit code 反映的是「log 串完了沒」，不是「PipelineRun 成功了沒」。 PipelineRun 失敗時 log 一樣會串完，所以 exit 0。

這不是 bug 而是設計：tkn pipeline start 是「啟動」指令，不是「等結果」指令。 但任何把它包進 CI 的人，直覺都會以為綠 = 成功。

修法

從 tkn 的輸出抓 PipelineRun 名字，再自己問 Kubernetes：

sh '''tkn pipeline start node-pipeline -n tpipeline -s pipeline --showlog \
        --use-param-defaults -p ... 2>&1 | tee tkn.log'''
sh '''PR=$(sed -n "s/^PipelineRun started: //p" tkn.log | head -1)
      ST=$(oc get pr "$PR" -n tpipeline \
           -o jsonpath="{.status.conditions[0].status}/{.status.conditions[0].reason}")
      echo "PipelineRun=$PR status=$ST"
      case "$ST" in True/*) ;; *) echo "PipelineRun 未成功"; exit 1;; esac'''

兩個小坑：

1. tkn 第一行輸出是 PipelineRun started: node-pipeline-run-xxxxx。別用 awk '{print $3}'——在 Groovy 的三引號字串裡 $3 會被當成 Groovy 變數吃掉，拿到空字串。sed 沒這個問題。
2. 沒給的 optional 參數，tkn 會互動式詢問。Jenkins 沒有 TTY，直接 Error: EOF。所有參數明傳，再加 --use-param-defaults 保險。

怎麼確認你自己的環境有沒有中

找一對同時間的 Jenkins build 和 PipelineRun：Jenkins SUCCESS、PipelineRun Failed。 有一對就是中了。不需要看 Jenkinsfile，結果會說話。

修完以後反向再驗一次：Tekton 12/12 綠、Jenkins 也要綠。我第一版的 awk 寫法就是反向壞掉——Tekton 全綠、Jenkins 因為抓不到名字而紅。兩個方向都對了才算修好。

更一般的版本

這是「fire-and-forget 包裝」的通病：任何 xxx start、xxx trigger、xxx submit 指令， exit code 都只代表「送出去了」。包進 CI 時要問自己：我檢查的是送出，還是結果？

在 lab 裡按一次看看：ocp-pipeline-lab 的 make build，Jenkins 的 node_build_pipeline job 已經帶狀態檢查； 把第二個 sh 拿掉再跑一次壞的 build，就能親眼看到假綠。