Implement version component context interpolation

What does this MR do and why?

Implement version component context interpolation

This is the third and final step of adding component context to CI interpolation. In the first step, we prepared the codebase by refactoring YAML context passing. In the second step, we added component.name and component.sha to interpolation. In this final step, we're adding component.version.

The version interpolation resolves to the actual semantic version tag when using shorthand versions (like @1.0 resolves to 1.0.2) or ~latest (resolves to the latest semver tag). When using a direct SHA, branch name, or non-catalog-resource project, the version returns nil.

This allows component authors to reference the same version in their templates as users specify when including the component, enabling use cases like matching container image tags with component versions.

This feature is behind the ci_component_context_interpolation feature flag.

References

Ref	Link
Issue	Components - Allow interpolation to use local c... (#438275)
Step 1	Prepare CI interpolation logic for component co... (!205999 - merged)
Step 2	Implement name and sha component context interp... (!206183 - merged)
Step 3	<<-- HERE-->>

How to test

Create a catalog resource project with these files:

templates/component-1.yml:

spec:
  component: [name, sha, version]
  inputs:
    compiler:
      default: gcc
    optimization_level:
      type: number
      default: 2
    job_name:
---
test-$[[ inputs.job_name ]]:
  script:
    - echo "Building with $[[ inputs.compiler ]] and optimization level $[[ inputs.optimization_level ]]"
    - echo "Component $[[ component.name ]] / $[[ component.sha ]] / $[[ component.version ]]"

Create .gitlab-ci.yml:

include:
  # Test with full version
  - component: gdk.test:3000/components/component-test-project-for-interpolation/component-1@1.0.0
    inputs:
      job_name: "full-version"
    rules:
      - if: $CI_COMMIT_TAG == null

  # Test with shorthand version (should resolve to 1.0.2)
  - component: gdk.test:3000/components/component-test-project-for-interpolation/component-1@1.0
    inputs:
      job_name: "partial-version"
    rules:
      - if: $CI_COMMIT_TAG == null

  # Test with ~latest (should resolve to latest version 1.0.2)
  - component: gdk.test:3000/components/component-test-project-for-interpolation/component-1@~latest
    inputs:
      job_name: "latest-version"
    rules:
      - if: $CI_COMMIT_TAG == null

  # Test with SHA (version should be nil)
  - component: gdk.test:3000/components/component-test-project-for-interpolation/component-1@$CI_COMMIT_SHA
    inputs:
      job_name: "sha-version"
    rules:
      - if: $CI_COMMIT_TAG == null

create-release:
  image: registry.gitlab.com/gitlab-org/cli:latest
  tags: [docker]
  script: echo "Creating release $CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG
  release:
    tag_name: $CI_COMMIT_TAG
    description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"

Create releases with tags 1.0.0 and 1.0.2.

Run a pipeline

With FF ci_component_context_interpolation enabled

With FF ci_component_context_interpolation disabled

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.