wbsong111이미지 → 차트 매핑
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) |
CHART_DIRS는 기본적으로 최신 버전 디렉토리 하나만 가리킨다. 차트를
업그레이드할 때 이 값을 교체한다 — 추가가 아니다. 옛 버전은 업그레이드 시점
태그로 동결된 채 카탈로그에 남는다(정적 카탈로그는 "버전 보관소"라 디렉토리 자체는
지우지 않는다 — 다만 자체 빌드 태그 자동 반영 대상에서는 빠진다). 근거:
MEMORY.md의 argo-cd/7.8.11 동결 사례(PR #28) — 차트 버전 갱신은 결국 배포
중인 앱 버전 관리와 묶여 간다. 차트 버전을 언제 올리는지(트리거) 자체는
catalog-update-pipeline SKILL.md
"언제 실행하나" 절 참고.
여러 버전을 의도적으로 병행 추적해야 하는 예외적 케이스(같은 이미지를 쓰는 두
메이저 라인을 동시에 지원해야 하는 경우 등)만 공백으로 여러 디렉토리를 나열한다 —
이 경우 왜 병행이 필요한지 CUSTOM-README.md나 커밋 메시지에 근거를 남긴다.