Gitlab - From application start to running the first CI pipeline

GItlab Nov 17, 2019

Here's what it takes to run your first Gitlab CI pipeline
Let's assume you have installed Gitlab or started it as a Docker container, described in this post, so you can follow the steps described in this post to make your first CI job. If you already have Gitlab CI deployed you can jump ahead to this part. Here are the steps needed to start your first Gitlab CI pipeline:

Create a root password

Once you start Gitlab for the first time you will be prompted to enter a password for the default "root" user, so go ahead and input the password

02_rootl-login
Once you log in with the root user you will be able to create users and projects.
3_createUsersProject

Create Gitlab user

We will go ahead and create as many users as we need, I'll create one admin user for now.
createUser1
createUser2
As stated, a reset link is sent by default to the users mail, but as we do not want to play with this functionality now we will just edit the new users password from root user and then log in to the new user.
EdditUserPass1
EditUserPassword2

At first login user is prompted to change the password (as it was set by the root user) So change it and log in:
ChangeUserPassword5

Create a project

Next, we can create a project from the users lading page:
Createproject

newproject-1

nowWeHaveAproject

Install and configure Gitlab runners

Gitlab runners are worker nodes that have Gitlabs system controller software installed and communicate with the Gitlab CI service.
There are several execution modes for the runner:
Shell, SSH, Docker, Kubernetes... Also, there is more than one way to get a running worker node - Install or run a docker instance. For the sake of this example, we will use the later and just start a preexisting docker instance for the runner
docker-runner

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

If you started the gitlab runner image you should now see it as docker ps output

runner-up

Register a runner

You can find detailed info about registering runners in Gitlabs docs, but for the sake of this exercise let's just describe the quickest way to do this when running a containerized version of the runner.
After confirming that the runners container is up you can connect to it from the console with command docker exec -it 1e6157e0c564 bash. You just need to substitute 1e6157e0c564 with the container id that you got when running the docker ps command.
The command will connect you to a bash session inside of the runners docker container and there you can run gitlab-runner register
and fill out the data required. In the setup described here the Gitlab address accessible from the runner is the local IP address of the PC on which we started docker versions of Gitlab and Gitlab-runner, as we forwarded the address from Gitlab to PC's ports 80 and 443 when we started it. The gitlab-ci token was acquired from the Config/CICD/Runners page on our Gitlab instance.
runnersucess

runnerregistered

runnerssettings

Note when running Gitlab locally add this to /etc/gitlab-runner/config.toml:
clone_url = "http://<localIP>"
configtoml

Create a .gitlab-ci.yml file

GitLab CI/CD pipelines are configured using a YAML file called .gitlab-ci.yml within each projects root directory.
Check out the usage reference here.
As long as you do not disable CI/CD and the .gitlab-ci.yml format is valid the stages and commands in it will be executed as defined.
Let's try something simple. Navigate to the project and add a new file named .gitlab-ci.yml and add these lines in it:

test:
  stage: test
  script:
    - curl wttr.in/london
  tags:
    - shell
    - qaautomation

When you push your commit and go to the root of the project you should see the job marked as passed (with a green tick sign)

projectdetails

cipipelineworks

Upon clicking on the job you should see some job details plus the content downloaded with curl in the job:
wttrworks

No rain in London today? The thing that gets validated for each job is the exit status code, which if returns 0 signifies that no errors have been found. As every Linux application returns a status code upon exit, exiting from an curl(or any other) command or test without an error will result in a job, stage and pipeline pass after all the commands and tests have finished.

You can learn more about GitlabCI pipelines here

Tags

Branimir Valentić

Hi, I am Branimir, Quality Assurance Automation Developer with 4+ years of experience in QA, Automation and DevOps topics.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.