菜单
Pipeline failure investigation -- enumerate ALL failed jobs/tasks, follow external CI links, classify errors. Extends darwin-gitlab-ops.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | darwin-pipeline-debug |
| description | Pipeline failure investigation -- enumerate ALL failed jobs/tasks, follow external CI links, classify errors. Extends darwin-gitlab-ops. |
| requires | ["darwin-gitlab-ops","darwin-pipelines-as-code"] |
| roles | ["developer"] |
Investigate failed pipelines by enumerating ALL failing jobs or tasks, drilling into external CI systems for detail, classifying each error, and retrying if transient.
Pipeline failures can originate from different trigger sources. Identify where the pipeline ran before investigating:
| Source | Where to find jobs/tasks | How to drill into failures |
|---|---|---|
| GitLab MR/PR pipeline | GitLab pipeline jobs list (MR/PR → Pipelines tab) | Job trace for native jobs; external CI link for Konflux jobs |
| GitLab push/tag pipeline | GitLab pipeline jobs list (project → CI/CD → Pipelines) | Same as MR/PR pipeline |
| Kargo promotion | Kargo stage steps (promotion status in Kargo UI/CLI) + linked MR/PR pipeline | Kargo step error message; then follow linked MR/PR pipeline if failure is CI-related |
| Tekton PipelineRun (direct) | K8s MCP or KubeArchive — list TaskRuns in the PipelineRun | TaskRun → step container logs |
| Konflux build (no GitLab) | K8s MCP or KubeArchive — find PipelineRun by component + commit | TaskRun → step container logs |
Use the event document to determine the source: Headhunter events have GitLab context, Kargo events have Kargo context (project, stage, promotion ID, MR/PR URL), Aligner events may reference either.
A pipeline can contain multiple jobs or tasks. Each may map to a separate execution environment (e.g., distinct Konflux PipelineRuns). The aggregation point (GitLab, Kargo, or the PipelineRun itself) reports failure if ANY job/task fails.
You MUST enumerate all jobs or tasks before investigating any single failure.
failed status.wait-for-merge, auto-merge, wait-for-update).Do NOT stop at the first failure you find. Multiple jobs/tasks can fail independently for different reasons. Report ALL of them.
When a pipeline has been in a non-terminal state longer than expected (not immediately after triggering -- the queue controller needs time to reconcile):
.status.conditions on the build cluster.reason: PipelineRunPending -- the pipeline is queued, not running.
Report queue state to FRIDAY rather than treating it as a slow pipeline.Admitted condition
for the definitive admission signal (see darwin-k8s-mcp for details).Include queue state in the report to FRIDAY so she can calibrate her deferral.
Read the job trace (last 50 lines) to extract the error message.
GitLab external jobs link to an external CI system. Follow that link to find the corresponding PipelineRun:
For Kargo-internal failures (not CI-related), extract the error from the promotion status. Common patterns:
wait-for-merge timeout: CI pipeline blocked the merge — investigate the MR/PR pipeline.auto-merge failure: merge conflicts or permissions — check MR/PR merge status.wait-for-update failure: submodule/image update step failed — check the Tekton TaskRun that performed the update.If the external link is unavailable or the data is pruned, state what you could not access and why.
After collecting errors from ALL failed jobs/tasks, classify each one:
Back-off pulling image, ErrImagePull, ImagePullBackOff on a step container. This means the pod never started and the task never ran. These are platform-wide issues affecting all pipelines that use the same image.HasLicense), policy violation.When multiple jobs/tasks fail for different reasons, infrastructure failures (image pull, platform outage) take priority in the report because they indicate systemic issues beyond the current pipeline. Code/compliance and orchestration failures are still reported but noted as potentially independent.
After retesting:
running or pending:
success: report that retry resolved the issue.failed: enumerate failed jobs/tasks again (Step 1) and report updated errors.Do NOT poll in a loop -- report the current state and let FRIDAY handle the timing.
Do NOT tag individual users (@username) in MR/PR comments or anywhere else. Do NOT query project/group members to find usernames to tag. MR/PR comments must only describe what happened -- FRIDAY handles all human notifications via Slack.
Always end your response with a clear recommendation for FRIDAY. Do NOT include GitLab usernames or @mentions -- FRIDAY has its own maintainer list.
Report format when multiple jobs/tasks failed:
Pipeline source: {GitLab MR/PR | GitLab push | Kargo promotion | Tekton direct}
Failed jobs/tasks (N total):
1. [job-name] — {error classification}: {specific error}
2. [job-name] — {error classification}: {specific error}
Priority: {infrastructure | code | compliance | orchestration}
Safety rules for modifying Dockerfiles and Containerfiles. Use when editing container build files.
MR/PR context gathering and diagnostic reporting guidelines. Activates when working on events that reference MRs/PRs or when reporting investigation findings.
Team coordination for implement and test modes. Developer and QE use team_send_results for final reports, team_huddle for mid-task questions to FRIDAY.
GitOps workflow rules for modifying infrastructure via git. Use when cloning repos, modifying Helm values, committing, pushing, or verifying deployments.
MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.
Report findings and status updates to the Darwin FRIDAY. Use team_send_results for final reports (task modes). In message mode, use team_send_message instead.