Further deduplication opportunities for Tekton *-pull-request.yaml files

[coderabbitai]

Background

This issue continues the conversation started in PR #1501 and specifically in this comment thread about further deduplicating the *-pull-request.yaml files in the .tekton directory.

Current State

After the refactoring in PR #1501, we successfully extracted the common multiarch-pull-request-pipeline into its own file. However, there are still opportunities for further deduplication between the runtime-specific PipelineRun files:

• .tekton/odh-pipeline-runtime-minimal-cpu-py311-ubi9-pull-request.yaml
• .tekton/odh-pipeline-runtime-minimal-cpu-py312-ubi9-pull-request.yaml

Analysis: Both files are nearly identical (53 lines each) with only 7 component-specific variations:

1. Component identifier: py311 vs py312
2. Python version paths: ubi9-python-3.11 vs ubi9-python-3.12
3. Dockerfile paths: runtimes/minimal/ubi9-python-3.11/Dockerfile.cpu vs runtimes/minimal/ubi9-python-3.12/Dockerfile.cpu
4. Metadata fields: names, labels, service accounts, and trigger paths

Approaches Considered

1. Shell Script Templating ❌

Initially considered creating template files with environment variable substitution using envsubst, but this approach was rejected in favor of native Tekton mechanisms.

2. Native Tekton Parameter Substitution ✅

Using Tekton's native $(params.NAME) syntax within pipelines and PipelineRuns. However, this has a limitation: parameter values in spec.params are treated as opaque strings and don't support variable substitution within them.

3. TriggerTemplates ❌

Not available in Konflux since it uses Pipelines as Code (PaC) instead of Tekton Triggers.

4. PAC Templating ❌

Advanced PAC templating features like {{ custom_param }} syntax are not supported in Konflux.

Konflux-Specific Constraints

This project uses Konflux (https://konflux-ci.dev/), which has specific limitations:

• No TriggerTemplates: Konflux uses PaC instead of Tekton Triggers
• Limited PAC Templating: No {{ custom_param }} syntax support
• GitOps-First: Designed for explicit, declarative PipelineRun files
• Recommended Pattern: Centralized Pipeline + Individual PipelineRuns

Final Recommendation

Status Quo is Optimal ✅

Based on Konflux documentation and best practices, the current approach is actually perfectly aligned with Konflux patterns:

1. Centralized Pipeline ✅ (multiarch-pull-request-pipeline.yaml)
2. Individual PipelineRuns ✅ (component-specific files)
3. Shared Logic ✅ (extracted into the common pipeline)

The deduplication already achieved by extracting the common pipeline logic is the recommended Konflux approach. Further templating would go against Konflux's GitOps-first, declarative philosophy.

Optional Enhancement

If maintenance burden becomes an issue, a simple development-time generation script could be used as a maintenance tool (not runtime requirement):

# .tekton/generate.sh (development tool only)
#!/bin/bash
for runtime in py311 py312; do
  version_dot=${runtime#py}
  version_dot=${version_dot:0:1}.${version_dot:1}
  
  envsubst < template.yaml > "odh-pipeline-runtime-minimal-cpu-${runtime}-ubi9-pull-request.yaml"
done

Key Learnings

1. Always consider native Tekton mechanisms first before external templating
2. Konflux has specific patterns that differ from pure Tekton
3. Current approach is optimal for the platform being used
4. GitOps-first design sometimes means accepting some duplication for clarity

References

• Original PR: RHOAIENG-30439: tekton: factor out the common multiarch-pull-request-pipeline into its own file #1501
• Comment thread: RHOAIENG-30439: tekton: factor out the common multiarch-pull-request-pipeline into its own file #1501 (comment)
• Konflux Documentation: https://konflux-ci.dev/docs/
• Konflux Centralized Pipeline Pattern: https://konflux-ci.dev/docs/patterns/centralize-pipeline-definitions/

Conclusion

No action required - the current implementation follows Konflux best practices. This issue serves as documentation of the investigation and rationale for the current approach.

[jiridanek]

Relevant Red Hat docs

• https://docs.redhat.com/en/documentation/red_hat_openshift_pipelines/1.19/html/pipelines_as_code/creating-pipeline-runs-pac#creating-pipeline-runs-pac

[jiridanek]

Minor Suggestion

The example generate.sh script is a great idea. To make it slightly more robust and clear, you could show how the variables would be set for envsubst, as it only substitutes environment variables.

Slightly Enhanced Script Example:

This version makes it clearer that the variables must be exported to the environment for envsubst to work.

#!/bin/bash
# .tekton/generate.sh (development tool only)
#
# Generates component-specific PipelineRuns from a common template.
#
# Usage: ./generate.sh

TEMPLATE_FILE=".tekton/template.yaml"

generate_pipelinerun() {
    export RUNTIME_ID="$1" # e.g., py311
    export PYTHON_VERSION_PATH="ubi9-python-3.${1:2}" # e.g., ubi9-python-3.11
    export DOCKERFILE_PATH="runtimes/minimal/${PYTHON_VERSION_PATH}/Dockerfile.cpu"

    OUTPUT_FILE=".tekton/odh-pipeline-runtime-minimal-cpu-${RUNTIME_ID}-ubi9-pull-request.yaml"

    echo "Generating ${OUTPUT_FILE}..."
    envsubst < "$TEMPLATE_FILE" > "$OUTPUT_FILE"
}

# Generate for all desired runtimes
generate_pipelinerun "py311"
generate_pipelinerun "py312"

echo "Done."