Adapt Container Scanning to different build processes

Description

Container Scanning requires a built Docker Image of the project. This is working fine in Auto-DevOps where the build job is building and pushing a image tagged with the Git commit sha at the beginning of the pipeline, making it available to the container_scanning job in the test stage.

graph LR
    A[build] --> B[test]
    B --> C[release]

For non Auto-DevOps project though this workflow doesn't fit well as the docker image is sometime built in the later stages of the pipeline. When the project is a tool that is released as a Docker image (e.g. gitlab-runner) the release step is actually pushing the image on the registry which we don't want to happen before the Image has been analyzed.

graph LR
    A[test] --> B[release]

Please remind that container_scanning is using Docker in Docker so there is no cache available, which requires to push the image to be analyzed in some registry to have it available in that job.

Proposals

Proposal-1: temporary build

We ask user to add a preliminary step to buid and push a temporary image that is then given to the container_scanning job. This is really close to what Auto-DevOps is doing.

graph LR
    A[tmp_build] --> B[test]
    B --> C[release]

Pros:

• this can left untouched the existing release process of the project

Cons:

• pollutes a bit the pipeline with a job that is only necessary to our own tools.
• creates a lot of useless images on the registry... this may be a blocker for some usages.

Proposal-1-bis: reusable temporary build

This is close to Proposal-1 except that here the image built in the build step is reused by the release step to just re-tag instead of rebuilding from scratch.

graph LR
    A[build] --> B[test]
    B --> C[release]

Pros:

• this saves some resources as we don't rebuild the same image

Cons:

• requires the user to adjust the release process to this new pipeline
• creates a lot of useless images on the registry... this may be a blocker for some usages.

Proposal-2: integrated build

Instead of pre-building the docker image in a preliminary job, we integrate that step into the container_scanning job. This will allow the job to have it's own local docker image to analyze without having to push it on any registry.

graph LR
    A[test] --> B[release]

Pros:

• can be easily achieved for simple projects, e.g. just take the Dockerfile in the repository's root

Cons:

• some specific setup on complex project may require customization.
• not optimum as we'll build the image twice or more depending on the project's pipeline.

Links / references