In this demo, we will be setting up a continuous integration lab environment.
And strictly speaking, this is not part of Dockle, but hopefully by showing you
how easy it is to set up your own continuous integration environment, you will
be able to follow along with the rest of the demos. First we're going to clone
the gitlab‑demolab repository.
Then we're going to use docker‑compose to fire up all Docker instances.
Then we're going to create a GitLab project.
We will be adding our SSH key in order to be able to push to that
repository, and we'll push the tools‑image repository that we cloned in the
previous demo to our newly minted GitLab instance. The code can be found on
GitHub under /PeterMosmans/gitlab‑demolab. There you can also find
extensive instructions on its usage.
Let's go back to our console. Let's clone the repository which contains the code
to spin up our GitLab instance, let's cd to that directory, and now in order to
make sure that we're doing the exact same code,
I'm going to check out the version tagged 1.0.0. This ensures
that you will see the exact same thing when recreating the lab as
you'll see me doing during this demo.
Let's clear the screen. As I mentioned before,
detailed instructions about it's usage can be found in the README file. For
now, I'm going to copy the supplied environment variables to a .env file.
The .env file contains all settings for this specific GitLab instance. And
here you can select a strong password,
a strong token, and the ports on which you will access the GitLab instance.
I'm happy with these defaults, and all that's left to do is spin up
our GitLab instance. We'll do that by running docker‑compose up,
because you need to have Docker Compose installed as well, and
let's supply the ‑‑detach flag to make sure it's running in the
background. That was it.
After a while, depending on how fast or how slow your machine is,
you should be able to access the GitLab web interface on the URL
and port specified in the .env file. In our instance, this is going
to be gitlab on port 8080.
I already made sure that gitlab resolves to localhost.
So let's switch to the web interface.
Now let's visit the address that we specified in the .env file, gitlab:8080.
And as you can see, GitLab is already up and running. Hooray! Now
let's enter root as username and the password that we specified in
the .env file. Click on Sign in, and we successfully signed in on
our local GitLab server.
Let's now create a new project by clicking on the New project link. Let's
select blank project, and for Project name let's select tools‑image. As we want
to push the repository that we cloned earlier to this repository, the
tools‑image repository, let's make sure that this is an empty repository, so
I'm going to deselect Initialize repository with a README. Let's click on
Create project, and conveniently, GitLab now reminds us that we haven't yet
uploaded the public SSH key,
which we will need if we want to push our code to this repository.
So I'm going to do that right now.
I'm going to click on Add SSH key, and then I'm going to paste in the public
SSH key which I'm going to use to access this repository.
Let's click on Add key, done. If we now go to the project page by
going to Menu, Projects, Your projects, and let's click on the
freshly created tools‑image repository, here we can see the
project that we just created.
Now let's go back to the console and push our earlier cloned
tools‑image repository to this server.
Let's go to the tools‑image directory.
This is the repository we cloned earlier from GitHub. Now we're
going to push this repository to our own GitLab server. First let's
create a new branch called ci. You can do that by performing a git
checkout with the ‑b flag.
Now we're going to add our GitLab server as a git remote by performing the
git remote add command and specifying the repository.
And finally, let's push our code to the GitLab server.
We can do that by performing a git push upstream.
This is the first time we connect to our GitLab server.
I'm going to accept the public key, and it pushed our code.
Let's go back to the GitLab web interface.
Let's refresh the page, and you can see it pushed our
code successfully to this repository.
Now this repository already contains a basic GitLab pipeline definition.
That's the file called .gitlab‑ci.yml. If we click on the
file, we see our basic pipeline definition.
And this is very standard, it contains a build stage and a test stage.
The build stage builds our Docker container and the test stage tests whether
everything is correct. If you now go to the menu item on the left, CI/CD, and
click on Pipeline, huh, the pipeline failed.
Okay, this was not what I was expecting.
What I was expecting is that the pipeline would run successfully
the build stage, as well as the test stage.
You might see different results.
You actually might see that the test stage works.
I'm going to click on the pipeline.
The build stage was successful, the test not, this seriously surprises me.
I'm going to click on test to see what went wrong. And here I
can see that the npm outdated test fails.
So this is actually a great example of an automated test that
fails without you having touched the code.
Why does it fail? Because the package has been considered outdated. This project
uses a Docker image as base, and apparently that base image now contains an
outdated library, therefore, the test fails even if the test ran successfully
the day before or even an hour before. Now,
you might see a different result because this issue
might have been resolved by now.
However, this is not important for the rest of our demo.
What is important is that we have our GitLab server
up and running to test CI/CD with, we have a pipeline up and running,
and in the next clip, we're going to add some Dockle to this
pipeline, what this whole course is all about.