Tekton 컨텍스트 디렉터리 Dockerfile 경로 불일치

이 페이지는 2026년 5월 26일 analysis-svc CI 실패에 대한 사고 회고입니다. 변경 사항은 일상적인 Docker 컨텍스트 마이그레이션처럼 보였지만 이전 템플릿 형태에서만 작동하는 암시적 Tekton 기본값을 노출했습니다.

실패한 것

analysis-svc는 서비스 로컬 Docker 빌드 컨텍스트에서 repo-root 컨텍스트로 이동했습니다. 그래야 해당 Dockerfile이 libs/를 복사하고 공유 관측성 모듈을 사용할 수 있었기 때문입니다. 트리거 템플릿은 context-dir를 .로 업데이트했지만, 처음에는 그에 맞는 dockerfile-path를 추가하지 않았습니다.

이로 인해 kaniko의 효과적인 조회가 유효한 서비스 로컬 경로에서 누락된 repo-root 경로로 변경되었습니다.

확인된 원인

fastapi-build-deploy 파이프라인은 여전히 기본적으로 dockerfile-path를 Dockerfile로 설정합니다.

- name: context-dir
  type: string
  default: .
- name: dockerfile-path
  type: string
  default: Dockerfile

출처: lumie-infra/applications/tekton/ci-cd/manifests/pipelines/fastapi-pipeline.yaml

이전 서비스-로컬 컨텍스트를 사용하면 해당 기본값이 올바르게 해결되었습니다. 컨텍스트가 repo 루트로 이동한 후 동일한 기본값이 존재하지 않는 최상위 Dockerfile을 가리켰습니다.

현재 저장소가 여전히 증명하는 것

이제 고정 트리거 템플릿은 두 매개변수를 모두 명시적으로 전달하고 그 이유를 설명합니다.

- name: context-dir
  value: .
- name: dockerfile-path
  value: services/analysis/Dockerfile

출처: lumie-infra/applications/tekton/ci-cd/manifests/triggers/triggertemplate.yaml

현재 체크인된 주석은 이 사건에서 남은 불변 조건이기도 합니다. 서비스가 repo-root Docker 컨텍스트를 사용할 때마다 context-dir와 dockerfile-path는 한 쌍으로 처리되어야 합니다.

실패를 놓치기 쉬웠던 이유

손상된 변경 사항은 구조적으로 불완전했으며 명백히 잘못된 것은 아닙니다.

• 이전 템플릿에는 명시적인 dockerfile-path가 없었습니다.
• repo-root 컨텍스트를 사용하는 다른 서비스에는 하나가 있었습니다.
• Tekton은 파이프라인 기본값에서 누락된 매개변수를 자동으로 채웠습니다.

이는 kaniko가 런타임에 실패하기 전에 린트, 테스트 및 레지스트리 설정이 모두 통과되었음을 의미합니다.

지속적인 교훈

• 빌드 템플릿을 마이그레이션할 때 다르게 보이는 필드뿐만 아니라 전체 작업 스탠자를 복사합니다.
• 동일한 파이프라인이 여러 컨텍스트 셰이프를 지원하는 경우 작업 기본값보다 명시적인 트리거 템플릿 매개 변수를 선호합니다.
• 변경된 파일 규칙에 따라 필터링되는 웹훅 흐름에 대해 수동 PipelineRun 복구 경로를 유지합니다.

확인

cd Lumie
sed -n '1,40p' \
  lumie-infra/applications/tekton/ci-cd/manifests/pipelines/fastapi-pipeline.yaml
sed -n '488,508p' \
  lumie-infra/applications/tekton/ci-cd/manifests/triggers/triggertemplate.yaml

성공은 파이프라인이 여전히 기본적으로 dockerfile-path를 Dockerfile로 설정하고 analysis-svc 트리거 템플릿이 repo-root 빌드에 대해 이를 명시적으로 재정의한다는 것을 의미합니다.