Skip to main content

Tekton Context Dir Dockerfile Path Mismatch

This page is an incident retrospective for the May 26, 2026 analysis-svc CI failure. The change looked like a routine Docker context migration, but it exposed an implicit Tekton default that only worked for the old template shape.

What failed

analysis-svc was moved from a service-local Docker build context to a repo-root context so its Dockerfile could copy libs/ and use the shared observability module. The trigger template updated context-dir to . but initially did not add the matching dockerfile-path.

That changed kaniko's effective lookup from a valid service-local path to a missing repo-root path.

Confirmed cause

The fastapi-build-deploy pipeline still defaults dockerfile-path to Dockerfile:

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

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

With the old service-local context, that default resolved correctly. After the context moved to repo root, the same default pointed to a non-existent top-level Dockerfile.

What the current repo still proves

The fixed trigger template now carries both parameters explicitly and explains why:

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

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

The current checked-in comment is also the incident's lasting invariant: context-dir and dockerfile-path must be treated as a pair whenever a service uses repo-root Docker context.

Why the failure was easy to miss

The broken change was structurally incomplete, not obviously wrong:

  • the old template had no explicit dockerfile-path
  • other services using repo-root context did have one
  • Tekton silently filled the missing parameter from the pipeline default

That meant lint, tests, and registry setup all passed before kaniko failed at runtime.

Lasting lessons

  • Copy the full working stanza when migrating a build template, not only the field that looks different.
  • Prefer explicit trigger-template parameters over task defaults when the same pipeline supports multiple context shapes.
  • Keep a manual PipelineRun recovery path for webhook flows that are filtered by changed-file rules.

Verification

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

Success means the pipeline still defaults dockerfile-path to Dockerfile and the analysis-svc trigger template still overrides it explicitly for repo-root builds.