product.gitlab-ci.yml

# 教學 job：在正常版 BE 跑五個 HTTP＋SQLite 驗收案例，再核對必要案例。
# 何時跑：這份檔案尚未被任何產品 include，也沒有建立 MR pipeline 的規則。
# 產品維護者接好 MR pipeline 後，MR 新增提交就應對該提交重跑本 job；
# 合併必須 pipeline 成功、固定程式與核准測試版本，也要由產品設定。
# 以下從 framework checkout 根目錄執行；實際產品要換成自己的 runner，
# 固定核准的測試／checker 與映像 digest。此 image tag 僅供教學。
# 「五案」包含成功與拒絕情境，不是只有正向測試。
# 不要改跑 run_demo.py：它是刻意注入故障、檢查預期失敗、再復原的演練，
# 演練成功不表示其中故障版可交付。正常產品 CI 只接受正常版測試全過。
quality-workflow-be-example:
  image: python:3.12-slim
  stage: test
  allow_failure: false
  script:
    - mkdir -p artifacts/quality-workflow
    - |
      # 第一步：runner 啟動服務與乾淨 DB，實際執行五個案例並寫出 JUnit。
      runner_status=0
      (cd examples/quality-workflow && python3 -m independent.harness \
        --junit ../../artifacts/quality-workflow/junit-be.xml) || runner_status=$?
      # 第二步：checker 只讀清單＋剛產生的報告，拒絕漏跑、跳過或失敗；
      # 把 runner 原始失敗一併帶入，避免後面的核對掩蓋前面出錯。
      python3 tools/check_required_cases.py \
        --plan examples/quality-workflow/acceptance-plan.json --role be \
        --junit artifacts/quality-workflow/junit-be.xml \
        --runner-exit-code "$runner_status" --json \
        > artifacts/quality-workflow/required-case-check.json
  artifacts:
    # 成功或失敗都保存原始報告與核對結果，開發與 reviewer 才能查原因。
    when: always
    reports:
      junit: artifacts/quality-workflow/junit-be.xml
    paths:
      - artifacts/quality-workflow/junit-be.xml
      - artifacts/quality-workflow/required-case-check.json
    expire_in: 30 days
# 本 job 不做 candidate／collect／contracts bot／Jira 狀態轉換。
# 只驗教學 BE 五案，不包含產品其他單元測試、FE 或真實 BE＋FE 整合。
# 測試紅：BE 操作者與開發 Agent 查實作；認為標準錯則提出問題交 reviewer。
# 環境紅：CI 維護者修環境後重跑，不能把環境錯誤算成有效測試結果。