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.