How to apply dynamic values to GitLab CI variables?


In my pipeline I need to build a docker image with a dynamically named artifact.

I know its prefix and suffix but the middle is subject to change (e.g. In the Dockerfile, I have an ARG that expects the dynamic value to be populated via a --build-arg. Essentially, the required syntax is --build-arg ARTIFACT=$(find build/ -name "artifact*zip" -exec basename {} \;).

As a couple complicating factors, I do not have the ability to change the name of this artifact – it must arrive in the docker image with its dynamic name. Second, my YML is leveraging a template, so I would prefer against simple export or hard-coded solutions.

What I really need is for the following YML to work

    jobLevelArgs: --build-arg filepath=$(find ${BUILD_DIR} -name "artifact*zip")

This variable needs to be populated by the time I use it with (e.g.) builds/, but is instead always the raw value of the string. It may be that there’s security impact preventing the subshell here.

I have pored over GitLab CI/CD variables | GitLab and I see a similar post went un-responded to over here: How to use dynamic variable in artifact path? .

Is there a way to effectively set a dynamic variable based on some file path like this that can be shared within a job (before_script to script) and/or across jobs?

I have found the following work-around but it is sub-par

    - export filepath=$(find ${CI_DIST_DIR} -name "*txt")
    - echo /kaniko/executor
      --context $CI_PROJECT_DIR/my-image
      --dockerfile $CI_PROJECT_DIR/my-image/Dockerfile
      --destination $CI_REGISTRY_IMAGE/my-image:latest
      --build-arg filepath=${filepath}

The reason this is sub-par is that I do not need this variable set here in the template, I extend this template and multiple jobs will not have any valid filepath (potentially throwing errors, making things more complicated than they need to be) and the relevant job extending this will also look mysterious without its most important argument being specified. I can leave a comment, but it’s dirty.

To me, this seems like a missing feature in GitLab.

Thanks for any input.