doc (?): variables to docker job runners passed differently than doc says wrt to variables to service containers
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
I am trying to pass variables into a docker container running a CI job. The documentation is unclear on how to do this.
I have added a deploy key, and added both public and private to ci project variables. In my job, I have a variables section as described here, in the section on passing variables to service containers:
https://docs.gitlab.com/ee/ci/variables/
The job spec for reference is (NB semantic release is configured to use @semantic-release/git, which needs to push assets in current branch, and GL_TOKEN with write access to repo wasn't working on prerelease branch):
deploy: # deploy using semantic release
stage: deploy
needs: ['test', 'lint']
image: timbru31/node-alpine-git:16
only:
# limit to branches / refs
refs:
- main
- alpha
- beta
# This matches maintenance branches
- /^(([0-9]+)\.)?([0-9]+)\.x/
# This matches pre-releases
- /^([0-9]+)\.([0-9]+)\.([0-9]+)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+)?$/
variables:
SSH_PUBLIC_KEY: $SSH_PUBLIC_KEY
SSH_PRIVATE_KEY: $SSH_PRIVATE_KEY
before_script:
- cp .release/* .release/.releaserc.yaml .
- yarn install
- apk --update add openssh-client
- eval `ssh-agent -s`
- echo \""$SSH_PUBLIC_KEY"\"
- echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add - > /dev/null # add ssh key
- mkdir -p ~/.ssh
- chmod 700 ~/.ssh
- echo "$SSH_PUBLIC_KEY" >> ~/.ssh/id_rsa.pub
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
- git config --global user.email "${CI_EMAIL}"
- git config --global user.name "${CI_USERNAME}"
script:
- yarn semantic-release
I would have thought that variables passed like this are communicated in to the container ... and indeed they are, in a way:

It seems counterintuitive that the variable is passed, but isn't substituted for, unlike the doc example for service containers. This could be a bug. Either way the doc on variables should clear up how to pass variables to docker runners.
