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
```yaml
# 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. !197655+
## 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.
```yaml
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:
```yaml
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.
issue
