The before_script definition in the codequality template does not allow non-template definitions to utilize it to docker login
Summary
The recent introduction of this before_script:
block seemed to have broken the running of a codequality fork. cc @morefice
before_script:
- source lib/gitlab/ci/templates/utils/env.sh
- export SOURCE_CODE=$PWD
The documentation mentions that it is "possible to override the URL to the Code Quality image by setting the CODE_QUALITY_IMAGE variable. This is particularly useful if you want to lock in a specific version of Code Quality, or use a fork of it"
https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#example-configuration
Steps to reproduce
When dealing with a forked docker image location in gitlab-ci, we need to docker login
first. The place we had docker login
was in the before_script:
. If this is missing, the message when the template's script:
runs is "denied: access forbidden".
The .gitlab-ci.yml definition is this:
include:
- template: Code-Quality.gitlab-ci.yml
code_quality:
variables:
CODE_QUALITY_IMAGE: "registry.gitlab.com/path/to/fork/in/private/repo"
CODECLIMATE_DEBUG: 1
before_script:
- echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin
artifacts:
paths: [gl-code-quality-report.*]
reports:
codequality: gl-code-quality-report.json
expire_in: 90 days
Since we define a before_script:
section in our CI to docker login
, the template's before_script:
section is being overridden and the job fails with the symptom that the SOURCE_CODE variable is not set. The variable is being set in the template's before_script:
section.
Results of GitLab environment info
GitLab Enterprise Edition 13.4.0-pre f2982a31 (Gitlab.com)
Possible fixes
If the template's before_script:
were moved into the first lines of script:
section, I believe would give more flexibility for non-template job definitions and this problem would not occur. Otherwise, I don't see a way to docker login
to support forked images without looking up and copying the template's before_script:
code into our CI's before_script:
and adding docker login to it. Then there is also the on-going issue of keeping this up-to-date to future changes to the template.