Overview

Design and implement a versioning strategy for ODH base container images that allows tagging existing images without triggering rebuilds, while working within Konflux pipelines

Problem Statement

Currently, base container images are only tagged with commit SHAs (e.g., quay.io/opendatahub/odh-midstream-cuda-base-12-8:a0b0540).

We probably need some sort of versioning (Semantic versioning could be suitable, e.g., v1.0.0, v1.1.0) to:

• Provide stable, predictable versions for users
• Support floating tags for easier adoption (v1.2, v1, latest)
• Enable clear release management and changelog tracking

Constraints

• Only Konflux pipelines have Quay.io write credentials
• Tagging must NOT trigger image rebuilds
• Modifying repository files (like app.conf) triggers pipeline path filters and causes rebuilds
• Must work within existing Konflux pipeline architecture

Recommended Approach: Git Tag-Triggered Konflux Pipelines

How It Works

1. Developer creates semantic version git tag (e.g., cuda-12.8-v1.2.3)
2. Git tag push triggers dedicated Konflux tagging pipeline (.tekton/*-tag.yaml)
3. Pipeline uses apply-tags task with ADDITIONAL_TAGS parameter to tag existing image by digest
4. No rebuild occurs - tags are applied to already-built image

Proposed Tag Structure

Per-component semantic versioning:

Rationale: Independent versioning allows different lifecycles (CUDA 12.8 can be at v2.0 while 12.9 is at v1.0). Do we need to support this ?

Why This Approach

✅ No rebuilds (tags existing images by digest)
✅ Git tags provide auditable version history
✅ Works within Konflux security model
✅ Leverages existing apply-tags task infrastructure
✅ Can apply floating tags automatically
✅ Decouples versioning from code changes

Rejected Alternatives

• File-based versioning (app.conf): Modifying app.conf triggers path filters and causes rebuilds ❌
• Manual Quay.io tagging: Not auditable, doesn't scale, no permissions for individual contributors ❌