[CUBRIDQA-1575] Put each failed sql and medium case's query and diff in the run summary

[tw-kang]

http://jira.cubrid.org/browse/CUBRIDQA-1575

Purpose

9/18 부터 gha-ci: test_sql 과 gha-ci: test_medium 이 머지 필수 체크다. 이제 sql·medium 의 실패가 머지를 막는다.

그런데 run summary 는 실패한 케이스의 이름만 보여준다. 왜 깨졌는지 — 쿼리와 diff — 는 summary 에 없다. 보려면 그 shard 의 Artifacts 에서 ctp_log.tgz 를 내려받아 풀고, 그 안의 JUnit XML 을 찾아 열어야 한다. 머지가 막힌 사람이 원인 한 줄을 보려고 매번 밟는 길이다.

shell 은 이미 다르다. #7889 이 실패 케이스의 수행 로그를 summary 에 접어서 싣는다. CircleCI 의 sql·medium 은 실패 케이스 목록조차 남기지 않았다. 그래서 새 필수 체크의 실패를 읽는 자리는 summary 하나인데, 거기에 원인이 없다.

재료는 이미 있다. CTP 는 sql·medium 에서도 실패 케이스마다 JUnit XML 에 <failure> 를 하나 남기고, 그 본문(CDATA)이 [Query] 와 [Diff] 다. shell 이 쓰는 것과 같은 것이다.

Implementation

자리 셋을 고쳤다.

1. sql·medium shard 가 JUnit XML 을 산출물로 올린다. shard 는 지금 실패 케이스의 이름을 담은 summary_info 만 올린다. 그 옆에 XML 을 test-results/ 로 같이 올린다 — shell 이 test-shell.xml 을 올리는 자리와 같다. 고르는 규칙은 CTP 엔트리포인트의 collect_xml 과 같게 뒀다: *.xml 중 옛 형식인 summary.xml 만 뺀다. 실물에서 shard 당 하나다.

2. collect 이 그 XML 에서 케이스별 본문을 뽑는다 — 순서가 아니라 이름으로 맞춘다. summary_info 는 어떤 케이스가 깨졌는지를, XML 은 왜 깨졌는지를 말한다. 두 파일은 CTP 의 다른 단계가 쓰므로 줄 순서가 같다는 보장이 없다. 그래서 failed.list 의 케이스 이름을 키로 쓴다. failed.list 의 형식과 rerun_from 이 읽는 내용은 그대로다.

본문을 뽑는 awk 는 shell 갈래가 쓰던 것 한 벌을 둘이 나눠 쓴다. 색인 없이 부르면 XML 이 곧 실패 목록이라 만나는 차례로 번호를 매기고(shell), 색인을 주면 그 색인이 가리키는 케이스만 채운다(sql·medium). sql 을 위해 같은 프로그램을 한 벌 더 두지 않는다.

3. summary 의 '전문' 링크에 박혀 있던 test-shell.xml 을 지웠다. suite 마다 XML 이름이 다르다 — shell 은 test-shell.xml, sql·medium 은 <os>_<testType>_<testBit>.xml 이다. 이름을 적어 두는 대신 shard 가 올린 파일에서 받는다. 없으면 예전 이름으로 떨어진다.

동작이 바뀌는 것

• sql·medium 에 실패가 있는 run 의 summary 맨 아래에 <suite>: the log of each failed case 가 붙는다. 케이스마다 접힌 블록 하나이고, 펼치면 [Query] 와 [Diff] 가 나온다. 실패가 없으면 아무것도 붙지 않는다.
• 예산은 #7889 의 것을 그대로 쓴다 — 50건까지, step 당 900 KB, 케이스당 상한을 넘으면 가운데를 접는다.
• shell 은 보이는 것이 같다. 이름을 유도해도 test-shell.xml 이 그대로 나온다.
• ctp_log.tgz 는 지금처럼 실패한 shard 에만 올라간다. XML 이 summary 로 올라와도 나머지 로그는 거기에 있다.

Remarks

• 파싱은 상용 실패 run 의 실물 XML 로 확인했다. run 35289524447(PR 7916, gha-ci: test_sql=failure)의 sql shard 03 산출물을 받아 그대로 돌렸다 — summary_info 의 :nok 10건이 로그 10개가 됐고 누락은 없다. 로그 하나는 884 B ~ 18 KB 라 10건이면 전부 통째로 실린다. ]]> 잔재가 남은 로그는 없다.
• XML 의 name= 은 sql/_13_issues/_14_1h/cases/bug_bts_13199.sql 같은 repo 상대 경로다. summary_info 를 다듬은 모양과 같아서 키가 맞는다.
• 엔트리포인트의 collect_xml 은 같은 glob 에 -newer $RUN_STAMP 를 더 건다. shard 는 그게 필요 없다 — pod 마다 CTP 를 새로 받으므로 앞 run 의 XML 이 그 자리에 있을 수 없다. 실물에서도 shard 당 하나였다.
• sql 은 debug 빌드로 돈다. 그래도 XML 파일 이름에는 빌드 모드가 안 들어간다(<os>_<testType>_<testBit>) — classname 에만 들어간다. 그래서 이름을 박지 않고 유도한다.
• 포크 lane 검증 — sql: run 35310935254 (엔진 develop 051d5f61d5, sql 17,466 케이스 · shard 10). shard 마다 test-results/linux_sql_64bit.xml 하나가 올라왔다(68 KB ~ 650 KB). 그 판에 실패가 1건 실제로 나서 새 step 이 끝까지 돌았다 — sql: cases 1 / shown 1 / per case 131072 bytes, wrote 1 of 1 case logs, 11716 bytes.
• ⚠ 그 run 의 결론은 failure 다. 갈래 둘 다 이 PR 과 무관하고 둘 다 그 뒤 해소됐다. ① shard sql 03 의 cbrd_20953.sql = 테스트케이스 답안이 엔진 PR #7874(CBRD-27382)보다 먼저 들어와 그때의 develop 엔진과 어긋났다 — [CBRD-27382] Store referential class in _db_index instead of an index row OID #7874 는 그 뒤 머지됐다(develop 1c5f1fd264). ② build (release) = 그 시각 러너 노드 하나의 GlusterFS 클라이언트 열화(복구함). 오히려 ①이 이 PR 이 겨냥한 상황을 그대로 만들어 줬다.
• 원인 둘이 풀린 뒤 같은 판을 다시 돌렸다 — run 35315842689, 엔진 develop 1c5f1fd264, sql 17,466 케이스 · shard 10, 전 job 초록.
• 포크 lane 검증 — shell(무회귀): run 35314819094 전 job 초록(20 케이스 · shard 5). shard 는 예전처럼 test-results/test-shell.xml 을 올린다. 링크 이름 유도도 상용 shell run 35307710569 의 실제 트리에서 test-shell.xml 을 그대로 준다 — XML 이 하나도 없을 때도 같은 이름으로 떨어진다.
• 합친 뒤 다시 확인했다(커밋 345ef7a364·4cf3353885). ① 지역 대조 — 상용 실패 run 둘의 실물 XML(shell 10건·sql 10건)에 옛 코드와 새 코드를 나란히 돌려 failed.list 와 로그 파일이 바이트까지 같은 것을 확인했다. ② 포크 shell run 35317867302 전 job 초록. ③ 포크 sql 을 일부러 #7874 머지 전 엔진(051d5f61d5)으로 돌려 같은 케이스를 다시 깨뜨렸다 — run 35318396111, collect 가 wrote 1 of 1 case logs, 11716 bytes 로 합치기 전과 같은 값을 찍는다.

🤖 Generated with Claude Code

https://claude.ai/code/session_013x4VVZUpZHMQm8uf4NdpKk

[github-actions]

✅ TC Merge Gate — Merge Allowed

All TC PRs are merged, closed, or not present.

TC Repositories & Branches:

• ✅ cubrid-testcases: No open TC PR (merged, closed, or not created)
• ✅ cubrid-testcases-private-ex: No open TC PR (merged, closed, or not created)

[github-actions]

🧪 TC Test Environment Ready

CircleCI Testing:

• CircleCI will automatically test using the branches below.

TC Repositories & Branches:

• cubrid-testcases Draft PR (Branch: tc/pr-7981)
• cubrid-testcases-private-ex Draft PR (Branch: tc/pr-7981)

Next Steps:

1. Wait for CircleCI tests to complete
2. If CircleCI tests failed, please check the test results and fix the issues.
3. When ready to merge this PR, please merge the TC PR first, then merge this PR.

[tw-kang]

@greptileai review

[greptile-apps]

이전 리뷰 이후 변경이 없고, 기존 지적도 검증 결과에 따라 해결되어 현재 상태는 병합해도 안전해 보입니다.

_{Reviews (4) · Last reviewed commit: "[CUBRIDQA-1575] Say why summary.xml is l..."}

[tw-kang]

@greptileai review

[tw-kang]

@greptileai review

[tw-kang]

/run all

[tw-kang]

/run all

[tw-kang]

/run rerun 35353004596

[tw-kang]

/run rerun 35357335650

[github-actions]

✅ TC Branch Finalized for cubrid-testcases-private-ex

Engine PR was merged.

Cleanup Results:

• Branch tc/pr-7981: Deleted

TC base branch is ready for the next PR.

[github-actions]

✅ TC Branch Finalized for cubrid-testcases

Engine PR was merged.

Cleanup Results:

• Branch tc/pr-7981: Deleted

TC base branch is ready for the next PR.