In order to identify the version that was used to build a container image and snapshot we should set the version as a label. The recommended implementation for this from the Konflux Notebook/LM is below.

*Image Labels:* These are metadata labels baked directly into the container image manifest during the build process. *This is the recommended approach for your use case.* These labels are permanent, travel with the image artifact, and can be inspected at any time. Crucially, they can be used to drive logic in later stages, such as the release process.

1. 1. 1. Recommended Solution: Setting a Dynamic Image Label

You can achieve your goal by passing your `RELEASE_VALUE` as a pipeline parameter and using it to set both a `BUILD_ARG` for your Dockerfile and a `LABEL` on the final image.

Here is a step-by-step guide to implement this in your `.tekton` pipeline definitions:

1. Add a Parameter to Your `PipelineRun`
First, modify your `PipelineRun` definition (e.g., `.tekton/ove-ui-push.yaml`) to accept your `RELEASE_VALUE` as a parameter. This makes the value available to the entire pipeline.

```yaml
# In .tekton/ove-ui-push.yaml
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: ove-ui-on-push
  annotations:
    # ... your existing annotations
spec:
  params:
    - name: release-value
      value: "quay.io/openshift-release-dev/ocp-release:4.20.0-rc.1-x86_64"
    # ... other params like output-image, etc.
  pipelineSpec:
    params:
      - name: release-value
        type: string
      # ... other pipeline spec params
```

2. Pass the Parameter to the `buildah` Task
Next, within the `pipelineSpec`, find your build task (e.g., `build-container` or `build-images`) and pass the `release-value` parameter to it. You will use it for both the `BUILD_ARGS` and the new `LABELS` parameter.

The `buildah` task in Konflux supports a `LABELS` parameter that directly applies labels to the output image.

```yaml
# In .tekton/ove-ui-push.yaml (within spec.pipelineSpec.tasks)
tasks:
  - name: build-container
    # ...
    params:
      # ... other params like IMAGE, DOCKERFILE, etc.
      - name: BUILD_ARGS
        value:
          - "RELEASE_VALUE=$(params.release-value)"
      - name: LABELS
        value:
          - "release_value=$(params.release-value)"
```

This configuration does two things:
`BUILD_ARGS`: Passes the value into your Dockerfile, exactly as you intended.
`LABELS`: Applies a label named `release_value` with the same value directly onto the image manifest.

Example: Using a Custom Task to Generate the Label
If your label value needs to be generated dynamically (e.g., from a file or a script), you can add a custom task before the build and pass its result to the `buildah` task's `LABELS` parameter. This follows the pattern of using one task's results as the input for another.

```yaml
# In .tekton/ove-ui-push.yaml (within spec.pipelineSpec.tasks)
tasks:
  - name: get-release-label-task
    taskSpec:
      results:
        - name: release-label
      steps:
        - name: generate-label
          image: ubi9/ubi-minimal
          script: |
            #!/bin/sh
            # Your logic to generate the label value
            echo -n "release_value=your-dynamic-value" | tee $(results.release-label.path)

  - name: build-container
    runAfter: [get-release-label-task] # Make sure build runs after label generation
    params:
      # ...
      - name: LABELS
        value:
          - "$(tasks.get-release-label-task.results.release-label)"
```

Downstream Value: Why This is Powerful
Setting the label directly on the image is the standard pattern because it enables powerful automation and traceability in the release phase:

Dynamic Release Tagging: The Release Service can read labels from your container image and use them as template variables in your `ReleasePlanAdmission` (RPA). This means you can automatically create release tags based on the version baked into your image at build time.

    **Example RPA `tags` configuration:**
    ```yaml
    # In your RPA mapping section
    tags: ["{{ labels.release_value }}", "latest"]
    ```

This creates a seamless flow where the `RELEASE_VALUE` you define for your build becomes a tag on your final released artifact in `registry.redhat.io`, providing excellent traceability.