CI Component testing vs. metadata access

GitLab CI/CD
, ,
1

Problem to solve

I have a GitLab CI component, which needs an associated docker image. Currently both template/component-name.yml and the Dockerfile live in the same git repository. I follow best practice and test the component, that is I have a .gitlab-ci.yml in the same project, which includes the component via include:component:$CI_SERVER_FQDN/$CI_PROJECT_PATH/component-name@$CI_COMMIT_SHA and adds a job ensure-job-added, which ensured that the component added a job to the pipeline. A 2nd job builds the docker image and tags it as gitlab.example.com/path/project:dev-$CI_COMMIT_REF_SLUG . The component, which adds that jobs, uses image: gitlab.com/pmhahn/ci-playground:dev-$CI_COMMIT_REF_SLUG

That work very reliably, but clutters the container registry with many old images: Only very few make it through QA, but as each new commit runs the above pipeline, many images are created.

To solve this my idea was to name release images differently: Basically I use rules:if:$CI_COMMIT_TAG to tag those images, which are created by a tag-pipeline, with the additional name v$CI_COMMIT_TAG.

With GitLab 18.6 CI/CD Components can reference their own metadata. This looks perfect as my component then can use component.version for tagged/released component and fall back to component.sha for those temporary development branches.

GitLab 18.7 finally added spec:input:rules, which looked perfect to archive this:

spec:
  component: [version, sha]
  inputs:
    image:
      rules:
        - if: '"$[[ component.version ]]" != "null"'
          default: "gitlab.com/pmhahn/ci-playground:v$[[ component.version ]]"
        - default: "gitlab.com/pmhahn/ci-playground:dev-$[[ component.sha ]]"

That does not work as the component.* information does not seem to get expanded.

Is there some (other) way to

  • prefer component.verion if it is available/used
  • fallback to component.sha

Steps to reproduce

To me it looks like component.version and component.sha cannot be used as defaults for some input.xxx.

To me it looks like there is no fallback mechanism like in bash’s ${comp_version+${comp_sha}} which prefers $comp_version if it is set, but falls back to $comp_sha otherwise.

To me it Which troubleshooting steps have you already taken? Can you link to any docs or other resources so we know where you have been?

Configuration

Add the CI/CD configuration from .gitlab-ci.yml and other configuration if relevant (e.g. docker-compose.yml). Alternatively, create a public GitLab.com example project that provides all necessary files to reproduce the question.

Versions

Please select whether options apply, and add the version information.

  • Self-managed
  • GitLab.com SaaS
  • Dedicated
  • Self-hosted Runners

Versions

  • GitLab 18.7.6
  • GitLab Runner 18.8.0: