Hello,
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. artifact-12345.zip
). 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
variables:
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/artifact-12345.zip
, 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
script:
- 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}
${jobLevelArgs}
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.