In this demo, we're going to add Dockle to a continuous integration pipeline.
To be more specific,
we're going to add it in the pipeline of the
project we saw in the previous demo.
We're going to automatically scan a container image, we're
going to verify the exit code in the pipeline,
and we're going to configure the scan results.
In our tools‑image repository, I'm going to open the pipeline definition file,
which is called .gitlab‑ci.yml.
I'm going to open it using my favorite editor,
which is Emacs, but of course it can be something else.
So this is the pipeline definition file of the pipeline
we saw in action in the previous demo.
Yes, where the test stage in my instance failed.
What we're going to do right now is add a new stage,
the lint stage,
where we're going to perform a dockle lint over our container image.
We're going to add a lint stage right after the build stage.
If you're not entirely familiar with the GitLab syntax for pipelines,
don't worry.
We're talking here about the concepts, and the pipeline syntax,
to be honest, is fairly similar for say,
for instance, Azure or AWS or other continuous integration environments.
Let's create a lint stage with the name lint,
and it's going to use the Docker image that we used
in one of the previous demos.
And I'm going to specify the name, goodwithtech/dockle,
and I'm going to specify the version number because I
want the test to be deterministic.
I'm also going to define the entry point.
Why is that?
Well, I want to execute my own commands when the container spins up,
and these commands can be defined in the script key.
So in the script key, I'm going to execute the Dockle executable.
But wait a minute.
Didn't we see in the previous demo that the image needed
access to the /var/run/docker.sock binding?
What if we don't want to do that because of, say, security reasons?
Is there a different way to execute the Dockle container
and still lint local container images?
Why yes, there is.
You can scan image files.
So what we can do is save the Docker image to a file
and let Dockle scan that file.
Let's create a new variable called IMAGE_TAR,
and that will contain the file name of the Docker image.
And then within the build step, we're going to execute the docker save command,
and we're going to save the freshly created Docker
image to a file called IMAGE_TAR.
As we want to use the IMAGE_TAR file in the next stage,
in the lint stage,
we have to instruct the lint stage to not clone a fresh repository,
but use the repository from the previous stage.
So we're going to add a variable, and for GitLab this is called GIT_STRATEGY,
and we're going to instruct it to not override the
repository from the previous stage.
And now we can use Dockle without mounting /var/run/docker.sock.
We just need to specify the ‑‑input parameter with the
name of the file called IMAGE_TAR.
That's all there is to it.
Let's save this file,
and in our console let's add this file .gitlab‑ci.yml to the Git repository.
Let's commit it with a nice commit message, say feat: add dockle linting step.
And now let's push our results upstream to our GitLab server,
and let's switch to the GitLab server web interface.
It automatically detected the changes in the pipeline
configuration and started running the pipeline.
If you now click on the running pipeline, we can see all the details.
The build stage was successful, as expected.
It's now running the lint stage, and that stage succeeded,
even though there were issues with the Docker image.
Let's click on the lint stage to see the details of Dockle.
And here you can see that Dockle actually found some issues.
There's even a fatal issue, but still the pipeline succeeded.
So what happened?
Well by default,
the exit code of Dockle signifies whether the test itself was run successfully,
and the test itself ran successfully; however,
the results were different.
In the next clip,
we're going to see how we can modify the pipeline in order
that it fails when it actually finds issues.