A brief introduction about how to setup Gitlab CI (part II).
In Setting up Gitlab CI (I): docker+gitlab-runner we already created a docker image for gitlab-runner, which will be our CI environment. Next step is define the behaviors of your CI processes.
Pipelines are the top-level component of continuous integration, delivery, and deployment.
If .gitlab-ci.yml has been set up correctly, you could see pipeline flow under CI/CD->Pipelines.
If CI was enabled in your gitlab projects, gitlab-runner will try to find a file named .gitlab-ci.yml in your repository root. This file will tell gitlab-runner what should be done during CI process.
You need to specify the docker image and environment variables gitlab-runner are going to use at very beginning:
In our case we use the image from local docker hub.
In normal cases, our pipeline should have 3 stages roughly:
Stages can be split into several jobs like:
- code/commit style check
- downloading build dependencies
- build code
- run unit test
- run integration testing
In .gitlab-ci.yml, job can be defined as:
script defines shell scripts which will be executed by gitlab-runner.
Each job must have a unique name, but there are some reserved keywords can’t be used as job name:
Job name also can start with a dot(.) like .job. If a job name started with a dot, it will be ignored by gitlab CI(gitlab-runner will skip it).
There are a lot of features can be defined in .gitlab-ci.yml. Go to GitLab CI/CD Pipeline Configuration Reference for more details.