Files
service-catalog/catalog/image-map
wbsong111 3d3d508d04 apisix 차트를 2.16.0에서 2.17.0으로 올리고 발행된 3.18.0 자체 빌드 태그를 반영한다
hardened-containers가 apisix 3.17 라인 EOL로 3.18.0을 게이트 PASS로 새로 발행했다
(hardened-containers 커밋 3518f98: "3.17 line went EOL"). 이게 이 카탈로그의
차트 버전 갱신 트리거다 — appVersion을 3.18로 맞추려면 차트도 2.17.0(appVersion
3.18.0)으로 올려야 한다.

breaking_change_check: breaking=false. 다만 자동 diff가 못 잡는 실제 변경을
수동으로 하나 찾았다 — ingress-controller.enabled=true로 켜서 쓰는
apisix-ingress-controller 서브차트(1.2.0→1.3.0)에 새 CRD
l4routepolicies.apisix.apache.org가 추가됐다. helm_diff는 이 서브차트를 기본값
(off)으로만 렌더링해 애초에 스캔 대상에서 빠뜨린다 — CUSTOM-README.md에 수동
적용 안내를 남기고, 이 사각지대 자체를 catalog-update-pipeline SKILL.md에
기록해 다음 리뷰 때 놓치지 않게 했다.

catalog/image-map/{apisix,apisix-ingress-controller,adc}.env의 CHART_DIRS를
2.17.0으로 교체(2.16.0은 동결)하고, apply-published-tags.py로 발행된 실제 태그
(apisix 3.18.0-20260826, ingress-controller/adc는 최근 재스캔 리빌드분)를 반영했다.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-26 16:00:31 +09:00
..

이미지 → 차트 매핑

hardened-containers 레포가 발행하는 자체 빌드 이미지가 이 카탈로그의 어느 차트·어느 필드를 가리키는지 선언한다. 이 디렉토리에 파일이 있는 이미지 이름 = 이 카탈로그가 추적하는 자체 빌드 이미지 목록이다(.github/workflows/catalog-tag-update.yml이 이 목록을 기준으로 동작한다).

이관 배경: 이 정보는 원래 hardened-containers(당시 images/<image>/catalog.env)에 있었다. "어느 이미지를 쓰는가"는 카탈로그가 알아야 하고 "그 이미지를 어떻게 만드는가"는 hardened-containers 가 알아야 하므로, 레포 분리 시 이 지식을 카탈로그 쪽으로 옮겼다 — doc/migrations/self-build-images-to-hardened-containers.md 참고.

파일 형식 — <image>.env

<image>는 hardened-containers 레포의 images/<image>/ 디렉토리명과 정확히 같아야 한다 (published.json의 키도 같다).

의미
CHART_DIRS 이 이미지의 태그를 참조하는 차트 버전 디렉토리 (공백 구분, 여러 개 가능)
TAG_STYLE imageName(단일 필드 문자열) | split(registry/repository/tag 분리)
TAG_BLOCK split일 때 태그가 있는 블록의 점 구분 경로 (기본 image)

카탈로그는 한 차트의 여러 버전을 동시에 보관하는 "버전 보관소"다 — 이미지 하나가 여러 버전 디렉토리에 걸리는 것이 정상이다. 새 버전 디렉토리를 만들 때 이 매핑도 함께 갱신한다. 빠뜨리면 scripts/build/patch-catalog-tag.py가 그 파일을 검사조차 하지 않아 낡은 태그가 조용히 남는다(실측: cnpg-postgresqlcnpg-cluster/1.0.0만 매핑돼 있어 1.1.0이 낡은 태그로 남은 사고가 있었다).