메뉴
Jenkins 빌드 / 테스트 실패 로그 분석. 4-Stage 어디서 실패했는지 + 원인 + 수정 방향. 사용자가 "Jenkins 빌드 깨졌어", "파이프라인 실패", "왜 실패?" 등 요청 시. - Jenkins Stage FAIL / 빌드 console log 분석 필요
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | investigate-ci-failure |
| description | Jenkins 빌드 / 테스트 실패 로그 분석. 4-Stage 어디서 실패했는지 + 원인 + 수정 방향. 사용자가 "Jenkins 빌드 깨졌어", "파이프라인 실패", "왜 실패?" 등 요청 시. - Jenkins Stage FAIL / 빌드 console log 분석 필요 |
server-exporter Jenkins 4-Stage 실패 분석. Jenkins multi-pipeline 3종 (Jenkinsfile / Jenkinsfile_grafana / Jenkinsfile_portal) 단독 사용.
| Stage | 일반 실패 원인 |
|---|---|
| 1. Validate | 입력 형식 오류 (target_type 잘못 / inventory_json 파싱 실패 / IP 형식) |
| 2. Gather | precheck 실패 / vault 자격증명 stale / 외부 시스템 응답 변경 / fragment 침범 |
| 3. Validate Schema | sections.yml ↔ field_dictionary 정합 위반 / Must 필드 누락 / output envelope 6 필드 위반 |
| 4. E2E Regression | baseline 회귀 실패 (외부 시스템 변경 / 코드 회귀 / fixture stale) |
| Post (callback) | callback URL 무결성 (공백/슬래시) / 호출자 시스템 다운 |
gh run view)docs/05_inventory-json-spec.md) 비교## Jenkins 실패 분석 — Build #1234
### 실패 Stage: 4 (E2E Regression)
### 원인 (가설)
- HPE iLO5 2.x 펌웨어 응답에 새 필드 등장
- baseline_v1/hpe_ilo5_baseline.json과 diff 발생
### 증거
- Jenkins log: `tests/redfish-probe/test_baseline.py::test_hpe_ilo5 FAILED`
- diff: storage.controllers[0].vendor 필드 누락
### 수정 방향
1. probe-redfish-vendor로 펌웨어 응답 재프로파일링
2. update-vendor-baseline으로 baseline 갱신
3. PR 머지 후 재빌드
### 만약 코드 회귀라면
- recent commit list: HEAD~5..HEAD
- adapter dell_idrac9.yml 또는 hpe_ilo5.yml 최근 변경 검토
debug-precheck-failure, debug-external-integrated-feature, update-vendor-baseline, task-impact-previewci-failure-investigator, qa-regression-workerdocs/17_jenkins-pipeline.mdschema/sections.yml + schema/field_dictionary.yml + schema/baseline_v1/ 3종 정합 갱신 (rule 13 R1). schema 변경 후 호출. 사용자가 "schema 정합 갱신", "field dictionary 동기화", "ERD 갱신" (server-exporter 어휘로는 schema doc) 등 요청 시 또는 schema 5개 이상 누적 변경 시 자동. - schema/sections.yml or field_dictionary.yml 수정 후 / 새 섹션 / 새 필드 / Round 검증 후 baseline 변경
구조화된 server-exporter 기능 명세서 작성. 사용자가 "명세서 써줘", "스펙 정리" 등 요청 시. - 구조화된 spec 필요 / PR 본문 / 문서화
server-exporter에 새 벤더(예: Huawei iBMC, Inspur, Ampere)를 3단계로 추가하는 절차 안내. vendor_aliases.yml + adapters/{channel}/{vendor}_*.yml + (선택) OEM tasks + vault + baseline + ai-context + docs 동시 갱신. 사용자가 "Huawei vendor 추가", "새 벤더 추가", "Huawei 지원하자" 등 요청 시 자동 호출. - 새 vendor가 호출자 시스템에서 요청됨 / 펌웨어 프로파일링 후 정식 지원 / 기존 generic fallback 한계 시
사용자 사이트 사고 환경 (HPE Gen12 / Lenovo XCC3 / Dell iDRAC8 / Cisco CIMC 등) 의 fixture를 캡처해 회귀 회피. cycle 2026-05-01 학습 — 사이트 사고 fixture 부재로 다음 reverse regression 위험. 사이트 envelope / probe 결과 / 펌웨어 응답을 tests/fixtures/redfish/{vendor}_{firmware}/ 에 저장 + tests/evidence/<날짜>-<vendor>.md 작성. 사용자가 "사이트 fixture 캡처", "사고 재현 입력 저장" 요청 시.
lab 부재 vendor 추가 (web sources 의무). cycle 2026-05-06 학습 — 4 신규 vendor (Huawei/Inspur/Fujitsu/Quanta) + Superdome Flex 의 lab 부재 web sources 패턴 라이브러리화. 사용자가 "Huawei iBMC 추가", "lab 없는 vendor 어떻게?", "vendor 추가" 등 요청 시 + lab 부재 명시 시. - rule 50 R2 9단계 + rule 96 R1-A web sources 의무 + vault SKIP 사용자 명시 승인
다중 worker cycle 자동화 (Phase 0 ticket 작성 → Phase 1 분석 → Phase 2 결정 → Phase 3 구현 → Phase 4 회귀 → Phase 5 종료). cycle 2026-05-06 학습 — 24 ticket × 5 worker 패턴 라이브러리화. 사용자가 "cycle 시작", "사용자 N 작업 묶음 ticket 으로 분해해줘", "cycle 자동화" 등 요청 시. - 3 항목 이상 작업 묶음 / 다중 worker 동시 진행 / 호환성 / 큰 리팩토링