This article introduces common components and their functions in application design.
Introduction#
Starting from GitLab 8.0, GitLab CI has been integrated into GitLab. We just need to add a .gitlab-ci.yml file to the project and add a Runner to enable continuous integration. With the upgrade of GitLab, GitLab CI has become more and more powerful. This article will introduce how to use GitLab CI for continuous integration.
Some Concepts#
Before introducing GitLab CI, let's take a look at some concepts related to continuous integration.
Pipeline#
A Pipeline is equivalent to a build task, which can include multiple stages such as dependency installation, testing, compilation, deployment to a test server, deployment to a production server, etc. Any commit or merge request can trigger a Pipeline, as shown in the following diagram:
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
Stages#
Stages represent build stages, which are essentially the processes mentioned above. We can define multiple stages in a Pipeline, and these stages have the following characteristics:
- All stages run in order, meaning that the next stage will only start after the previous stage is completed.
- The build task (Pipeline) will only be successful when all stages are completed.
- If any stage fails, the subsequent stages will not be executed, and the build task (Pipeline) will fail.
Therefore, the relationship between stages and Pipeline is as follows:
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
Jobs#
Jobs represent build jobs, which are the tasks executed within a stage. We can define multiple jobs within stages, and these jobs have the following characteristics:
- Jobs within the same stage are executed in parallel.
- The stage will only be successful when all jobs within the stage are successful.
- If any job fails, the stage fails, and the build task (Pipeline) fails.
Therefore, the relationship between jobs and stages is as follows:
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
Introduction#
After configuring the Runner, the next thing we need to do is to add a .gitlab-ci.yml file to the project root directory. Once we have added the .gitlab-ci.yml file, the build task will be automatically triggered every time we commit code or merge a merge request.
Do you remember how the Pipeline is triggered? The Pipeline is also triggered by committing code or merging a merge request! So what is the relationship between the Pipeline and .gitlab-ci.yml? In fact, .gitlab-ci.yml is just defining the Pipeline!
Basic Syntax#
Let's take a look at how .gitlab-ci.yml is written:
# Define stages
stages:
- build
- test
# Define job
job1:
stage: test
script:
- echo "I am job1"
- echo "I am in the test stage"
# Define job
job2:
stage: build
script:
- echo "I am job2"
- echo "I am in the build stage"
It's easy to write, right? Use the stages keyword to define the various build stages in the Pipeline, and then use some non-keywords to define jobs. You can use the stage keyword within each job to specify which stage the job corresponds to. The script keyword inside the job is the most important part and must be included in each job. It represents the commands that the job will execute.
Recall the relationship between stages and jobs mentioned earlier, and guess the result of the example above?
I am job2
I am in the build stage
I am job1
I am in the test stage
That's right! According to our definition in stages, the build stage should run before the test stage. Therefore, the jobs with stage: build will run first, followed by the jobs with stage: test.
Common Keywords#
Here are some common keywords. For more detailed information, please refer to the official documentation.
stages
Defines the stages. By default, there are three stages: build, test, and deploy.
types
An alias for stages.
before_script
Defines the commands that will be executed before any jobs.
after_script
Requires GitLab 8.7+ and GitLab Runner 1.2+
Defines the commands that will be executed after any jobs.
variables && Job.variables
Requires GitLab Runner 0.5.0+
Defines environment variables. If environment variables are defined at the job level, the job will use the job-level environment variables.
cache && Job.cache
Requires GitLab Runner 0.7.0+
Defines the files that need to be cached. At the beginning of each job, the Runner will delete the files specified in .gitignore. If there are files (such as node_modules/) that need to be shared among multiple jobs, we can only let each job execute npm install separately, which is inconvenient. Therefore, we need to cache these files. Cached files can be used across jobs and even across pipelines.
For specific usage, please refer to the official documentation.
Job.script
Defines the commands that the job will run. This is a required field.
Job.stage
Defines the stage of the job. The default value is test.
Job.artifacts
Defines the artifacts generated by the job. After the job runs successfully, the generated files can be preserved as attachments (such as binary files), packaged and sent to GitLab. We can then download these attachments on the project page in GitLab. Note that artifacts should not be confused with cache.