Subscribed @Legoktm and @Addshore which were involved in the migration toward Docker images and should have some familiarity with the ci-src-setup script.
Following a conversation with @dcaro we have the use case for reusing a CI docker image locally. Some of our images have an entry point invoking ci-src-setup.sh which initializes a git repository. It is handy when the image is run by Jenkins/Zuul since all parameters are set and there are no preexisting code, but for local use the script complains about lack of ZUUL_* environment variables and most probably one wants to run the image against local code rather than a patch in Gerrit.
This task is to have the ci-src-setup to only run its operations when it is executed under the CI environment. Jenkins always inject JENKINS_URL and our Jenkins instance also set the CI environment variable which might be easier to remember. So I guess we can have the script to skip its operations when either is set.
The script is defined in dockerfiles/ci-common/content/ci-src-setup.sh. It is included in the CI base images releng/ci-stretch and releng/ci-buster and placed under /utils. Thus images entry points usually invoke /utils/ci-src-setup.sh.
I guess we can do something such as:
if [[ ! -v JENKINS_URL && ! -v CI && ! -v ZUUL_URL ]]; then echo "Not in CI, skipping fetching the repository assuming code is mounted." echo "Set CI and ZUUL_* environment variables to force." exit 0 fi ... rest of the logic
Then when one runs the image locally, it would be expected the code has been mounted under WORKDIR (typically that is set to /src).
And if we want to reproduce what CI is doing we can locally set CI or the set of Zuul environment variables required by the script (ZUUL_URL, ZUUL_PROJECT, ZUUL_BRANCH, ZUUL_REF).
The example run scripts (dockerfiles/*/example-run.sh) should hopefully by fine since they set the Zuul environments variables in order to checkout code.