Components - Allow interpolation to use local context data

Problem

1. As a user I would like to create a component that uses a container image that is also built during the release process of the component itself. For example:

• I tag version 1.0 of the repo.
• A tag pipeline runs and build the Docker image my-image:1.0
• The component yaml file uses by default the image that matches the same tag.

This problem cannot be solved using predefined CI variables because those are evaluated in the context of the consumer project, not the current file being evaluated.

Proposal

# templates/test-component.yml

spec:
  component: [name, version, ref]
  inputs:
    a:
      default: a
    b:
      default: b
    c:
      default: c
---
link-check:
  script:
    - echo "$[[ inputs.a ]] $[[ inputs.b ]] $[[ inputs.c ]]"
    - echo $[[ component.name ]]
    - echo $[[ component.version ]]
    - echo $[[ component.sha ]]

We are having $[[ component.name ]], $[[ component.version ]], and $[[ component.sha ]].

• name: The component name.
• version: The found version based on the passed parameter (group/project/component@abc).
  • Today, abc can be a full version (v1.2.3), partial version (v1, v1.2), latest, branch name (my-new-feature), or SHA (a14veg343fgr).
  • This returns a valid version only if the passed parameter refers to a released version.
  • This returns null otherwise.
• sha: The found SHA based on the passed parameter (group/project/component@abc).

Technical Details

1. Pass Config::Yaml::Context to Config::Yaml::Loader with variables.
2. Draft: POC - interpolation to use local context... (!197655 - closed)

Follow-up

The default function: $[[ component.version | default component.sha ]]

Workaround

Specify the component version twice - once in the include of the component and then in a custom input(s) for the component.

include:
  - component: gitlab.com/../component@3.5.1
    inputs:
      version: 3.5.1 

Then the inputs.version can be used so the same version of the image is being used:

my-job:
  image: registry.gitlab.com/../image-job:$[[ inputs.version ]] 

Note: Another option is to reference the image version in the pipeline template file in a commit just before creating the tag, so that the git revision content hardcodes the tag.