Misaligned Docker and Container-Scanning templates

DevSecOps
1

I’m seeing that the Docker and Container-Scanning gitlab templates point at different default images.

While playing with the Container-Scanning template I continually got permission denied errors when trying to run the following ci.

include:
- template: Container-Scanning.gitlab-ci.yml
- template: Docker.gitlab-ci.yml
stages:
- build
- test

After digging for a while I realized the Container-Scanning template was by default pointing at $CI_REGISTRY_IMAGE/master:latest while the Docker template was uploading by default to $CI_REGISTRY_IMAGE:latest.

The following template gets the two to align correctly. Is this a bug that needs to be reported? Users shouldn’t have to dig as hard as I did to figure out what makes the default CI setup with the two templates happy.

variables:
  CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE
  CI_APPLICATION_TAG: latest
include:
- template: Container-Scanning.gitlab-ci.yml
- template: Docker.gitlab-ci.yml
stages:
- build
- test
1 Like
2

From the Container-Scanning docs the actual syntax of Image name used in the template is $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA.

It is also worth mentioning that the Docker.gitlab-ci.yml template is using two different names based on if it’s master branch or not.

Aligning the two templates would be hard since you would need a case for master and other branch in the Container Scanning template as well. Not to mention MR pipelines. I would say we are talking pretty much about breaking changes. That’s why Container Scanning examples are probably not using the Docker.gitlab-ci.yml template.

The Docker.gitlab-ci.yml could use some love to include some options to be able to overwrite some stuff, but then the DinD is not really the way to go since it requires Privileged runners and maybe Kaniko is better option.

In my experience the templates provided by GitLab are really just for basic use and I always have to use the variables to customize their behavior.

2 Likes