84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
---
|
|
name: miaobao-nightly-ci-report
|
|
description: Produce the Miaobao nightly or mainline Drone CI digest when the user asks for recent failing CI, nightly CI reports, or main health; enforce fixed Chinese headings, exact build-step-error evidence, and no speculation.
|
|
---
|
|
|
|
# Miaobao Nightly CI Report
|
|
|
|
Use this in `/Users/zfc/code/real_product/miaobao` when the task is a nightly/mainline CI digest for Drone and the user wants a short Chinese conclusion built only from real build/log evidence.
|
|
|
|
Do not use this for fixing the failing code, broad PR closeout, or speculative CI triage without Drone access.
|
|
|
|
## Inputs / Context
|
|
|
|
1. Confirm the repo is `intelligrow/miaobao`.
|
|
2. Confirm `DRONE_SERVER` and `DRONE_TOKEN` exist in the environment.
|
|
3. Resolve how many recent failed builds to inspect; default to `10` if the user does not specify a count.
|
|
4. Group target builds by branch type:
|
|
- `refs/heads/main`
|
|
- PR builds
|
|
- tag builds if they matter for "谁被挡住"
|
|
|
|
## Procedure
|
|
|
|
1. Fetch the latest build list from Drone.
|
|
2. Identify recent failed builds in recency order.
|
|
3. For each cited build:
|
|
- fetch build detail first
|
|
- read `stages` / `steps`
|
|
- derive the exact log path `/api/repos/intelligrow/miaobao/builds/<build>/logs/<stage>/<step>`
|
|
4. Do not guess log URLs from step names.
|
|
5. Extract only concrete evidence needed for the report:
|
|
- build number
|
|
- branch / PR / commit when available
|
|
- failing step name
|
|
- failing test file or exact error text
|
|
6. Separate failure buckets before summarizing:
|
|
- shared mainline code/test/lint problem
|
|
- PR-only clone/setup issue
|
|
- stale/expired failure already superseded by later green builds
|
|
- tag-line health if the user cares about release blockage
|
|
7. Write the result in this exact order:
|
|
- `今日结论：`
|
|
- `main 是否健康：`
|
|
- `最新失败：`
|
|
- `谁被挡住：`
|
|
- `问题分类：`
|
|
- `证据：`
|
|
- `建议动作：`
|
|
8. Keep the wording Chinese-only, short, and plain.
|
|
9. If any required field cannot be proven from Drone, write `证据不够`.
|
|
10. End with one shortest action, for example:
|
|
- `修代码`
|
|
- `修测试`
|
|
- `修 CI`
|
|
- `重跑确认`
|
|
- `开 issue`
|
|
- `关闭旧 PR`
|
|
- `暂时不用处理`
|
|
|
|
## Efficiency
|
|
|
|
1. Start from build list -> build detail -> exact failing step log.
|
|
2. Reuse one evidence packet per build; do not reopen the same logs repeatedly.
|
|
3. Prefer the newest meaningful blocker first.
|
|
4. Stop once the shared failure signature is proven and the fixed report shape is complete.
|
|
5. Do not spend time on browser/UI checks for this workflow.
|
|
|
|
## Pitfalls
|
|
|
|
- If the report becomes speculative, cite only build detail plus the exact failing step log; otherwise write `证据不够`.
|
|
- If guessed log URLs fail, derive `/logs/<stage>/<step>` from build detail every time.
|
|
- If an old red build looks active, compare newest main, PR, and tag states before summarizing "谁被挡住".
|
|
- If PR clone/setup noise appears, classify it separately from product code/test/lint failures.
|
|
|
|
## Verification Checklist
|
|
|
|
- Output is fully in Chinese.
|
|
- Output uses the fixed heading order exactly.
|
|
- Every conclusion is backed by real Drone evidence or explicitly says `证据不够`.
|
|
- The report names exact build numbers and step names.
|
|
- Error text or failing test file is included when available.
|
|
- Main, PR, and tag states are not collapsed together incorrectly.
|
|
- The final action is one short recommendation, not a long remediation list.
|