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

Once you log in with the root user you will be able to create users and projects.

Create Gitlab user

We will go ahead and create as many users as we need, I'll create one admin user for now.
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.

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

Create a project

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



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 run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \

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


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.



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

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:

  stage: test
    - curl
    - 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)



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

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