[CUBRIDQA-1608] CI: retire CircleCI on develop and revert the CUBRIDQA-1506 measures

[tw-kang]

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

Purpose

develop 의 shell·sql·medium 은 이제 gha-ci.yml 이 다 돌린다. CircleCI 는 같은 일을 한 번 더 한다. 그 중복을 끝낸다.

같이 수명이 끝나는 것이 하나 더 있다. CUBRIDQA-1506 의 임시조치다. 두 PR 다 "CUBRIDQA-1501 에서 되돌린다" 고 스스로 적어 두었다.

• [CUBRIDQA-1506] CI: build the debug package on the runner node for shell tests #7618 — 클라우드 debug 빌드(290MB)를 30Mbps 회선으로 내려받는 대신 러너 노드에서 직접 빌드한다. cubrid-build-node executor 와 build-debug-node job 이 생겼다.
• [CUBRIDQA-1506] CI: suspend the develop build transport until the GHA migration #7640 — develop 머지마다 2×290MB 를 옮기던 store-build-develop 전송을 멈췄다.

둘은 develop 이 CircleCI 를 쓰는 동안만 뜻이 있다. 그래서 같은 PR 에서 끝낸다.

⚠ 문제 하나: comment_trigger.yml 에는 base 브랜치 필터가 없었다. 이벤트 페이로드에 base 가 없고, issue_comment 는 branches: 필터도 못 쓴다. 필터 없이 이 파일을 끄면 release/11.4·release/11.3 의 CI 까지 같이 죽는다.

Implementation

커밋 넷이다. 순서에 뜻이 있다 — 끄는 커밋이 먼저 오고, 되살리는 커밋이 뒤에 온다.

1. CI: stop running CircleCI on develop

.circleci/config.yml 은 CircleCI 가 빌드하는 커밋에서 읽는다. 그래서 develop 의 사본은 develop 과 develop 에서 딴 브랜치만 읽는다. build_test 워크플로에 when: false 한 줄이면 그 전부가 멈춘다. release/11.4·release/11.3 은 자기 사본을 들고 있다. 안 건드린다.

job 정의는 지운다. 뒤의 리버트 커밋이 이 파일 위에 얹혀야 하기 때문이다. .circleci/ 디렉토리 삭제는 구독 해지 때 한 번에 한다.

comment_trigger.yml 은 반대다. issue_comment 는 항상 기본 브랜치(develop)의 사본을 돌린다. 그래서 develop 의 사본이 저장소의 모든 PR 을 결정한다. Validate Command 단계가 Validate Command and Base Branch 가 되어, 명령 문법을 본 뒤 PR 의 base ref 를 읽는다. 범위는 gha-ci.yml 의 gate 와 같다.

base 브랜치	/run 코멘트가 깨우는 것
develop	gha-ci 만
feature/**	gha-ci 만
release/11.4, release/11.3	CircleCI (지금과 같다)

필터는 거르는 쪽만 적는다. 모르는 브랜치의 기본값이 "CircleCI 유지" 다. 새 release/* 계통이 생겨도 CI 가 조용히 죽지 않는다.

feature/** 도 같이 끊었다. feature/** 는 develop 에서 딴 브랜치라 자기 .circleci/config.yml 에 이미 when: false 를 들고 있다. CircleCI 에 POST 해도 빈 파이프라인만 생긴다.

base 를 읽으려고 job 에 permissions: pull-requests: read 를 달았다. gha-ci.yml 의 gate job 과 같은 권한이다.

2. CI: read the token the way the rest of the workflows do

github.token, secrets.GITHUB_TOKEN 이 아니다. 값은 같다. gha-ci.yml·tc-merge-gate·tc-branch-sync·tc-branch-finalize 가 전부 앞의 표기를 쓴다.

3·4. 1506 임시조치 리버트 (#7640 → #7618 순서)

git revert 두 건이다. 손으로 고친 곳은 없고 충돌도 없었다.

되살아나는 것 — store-build-develop job, build 의 develop release 패키징, build_debug 의 develop 보존용·shell 용 패키징.
사라지는 것 — cubrid-build-node executor, build-debug-node job(113줄), config 가 워커 디렉토리 cubrid-mirror·ccache-shell-debug 를 부르던 참조.

되살아난 job 은 하나도 안 돈다. 커밋 1 의 when: false 가 그 위에 있다. 커밋 순서가 그것을 보장하고, squash 머지라 develop 에는 한 커밋으로 들어간다 — 중간 상태가 develop 에 남지 않는다.

바뀌는 동작

머지 뒤 develop PR 에서 ci/circleci: build · ci/circleci: build_debug · ci/circleci: test_sql · ci/circleci: test_medium 체크가 사라진다. develop 에 머지할 때도 CircleCI 는 안 돈다.

watching PR #6585 의 중복도 같이 사라진다. 그 PR 은 develop 머지마다 24초 안에 for commit <sha> 를 자기 브랜치에 push 하는데, 그 커밋이 develop 머지 커밋(parents=2)이고 브랜치가 develop 에 behind=0 이다. 그래서 이 PR 이 머지되면 다음 자동 push 가 when: false 를 물고 온다. 하루 4~6회 돌던 build·build_debug 중복 쌍이 그 push 부터 멈춘다.

Remarks

되돌리는 방법 — 한 줄이다.

git revert <squash SHA>   →   머지

커밋 넷이 squash 로 한 커밋에 들어가므로, 그 커밋 하나를 되돌리면 지금 실제로 도는 설정이 그대로 돌아온다 — CUBRIDQA-1506 임시조치가 살아 있는 상태로. 반쪽 상태가 생기지 않는다.

⚠ when: false 만 지우는 식으로 되살리지 마라. 그러면 임시조치가 빠진 채로 CircleCI 가 돌아 클라우드 빌드 290MB 를 내려받는 옛 경로를 탄다. 동작은 하지만 느리다.

되살리기에 필요한 것은 설정이 아니라 인프라 셋이다 — CircleCI container agent(cubrid 네임스페이스의 container-agent) · 워커의 /home/build-cache 볼륨 · 워커의 /home/tc-repo. 2026-09-30 까지 셋 다 그대로 둔다. 그 뒤 CUBRIDQA-1529 가 정리한다.

⚠ 워커의 /home/build-cache/cubrid-mirror/ 를 지우지 마라. 리버트는 설정의 참조만 지운다. CUBRIDQA-1606 머지로 gha-ci 의 BUILD_MIRROR 는 /home/ci/seed/build 로 옮겨 갔으므로 이 디렉토리를 읽는 쪽은 이제 CircleCI 뿐이다 — 위의 되살리기 보험이다.

떼기 전에 등가를 확인했다 (2026-09-22 트래픽). 열린 PR 10건에서 gha-ci: test_sql·test_medium 과 ci/circleci: 짝을 맞댔다. gha 가 빨강인데 CircleCI 가 초록인 건은 0 이고, 반대(CircleCI 만 빨강)는 2건이다. 같은 창에서 인프라 사망은 0 이고 test_medium 은 shard 16/16 초록이다.

when: false 는 실물로 확인했다. 이 PR 의 head 가 바뀐 설정을 들고 있어 CircleCI 가 실제로 읽었다. 파이프라인은 errors: [] · state: created · workflow 0 개이고, 이 PR 에는 ci/circleci:* 체크가 하나도 안 붙었다. 설정 오류로 죽는 것이 아니라 정상 skip 이다.

이미 열려 있는 PR 은 바로 안 조용해진다. 머지 전에 딴 head 브랜치는 옛 설정 사본을 들고 있다. 그 브랜치는 push 할 때마다 ci/circleci: build·build_debug 가 계속 돈다. git merge develop 으로 develop 을 한 번 받으면 멈춘다. 이 체크는 비필수라 머지를 막지 않는다.

/run 이 CircleCI API 오류로 빨개질 수 있다. base 를 못 읽으면 job 이 could not read PR <n> 으로 실패한다. 일시 장애면 /run 코멘트를 한 번 더 달면 된다. 조용히 CircleCI 를 건너뛰는 쪽보다 낫다 — 그쪽은 develop 이 다시 CircleCI 를 타는 길을 연다.

• CircleCI 구독은 해지하지 않는다. 하위 브랜치(release/11.x)까지 gha-ci 를 적용한 뒤에 한다. .circleci/ 디렉토리 삭제도 그때다.
• 머지 뒤 release/11.4 PR 에 /run sql 을 한 번 달아서 CircleCI 가 여전히 도는지 확인한다.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FG2axaCtVCAn6jaAHVXYTj

[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-7960)
• cubrid-testcases-private-ex Draft PR (Branch: tc/pr-7960)

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 (2) · Last reviewed commit: "Merge remote-tracking branch 'origin/dev..."}

[tw-kang]

/run all

[github-actions]

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

Engine PR was merged.

Cleanup Results:

• Branch tc/pr-7960: 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-7960: Deleted

TC base branch is ready for the next PR.