This article introduces common components and their roles in application design.
Introduction#
Since 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 upgrades of GitLab, GitLab CI has become more powerful. This article will explain 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 same as the mentioned stages. We can define multiple stages in a Pipeline, and these stages have the following characteristics:
- All stages run sequentially, 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 step is to add a .gitlab-ci.yml file to the project's root directory. Once the .gitlab-ci.yml file is added, the build task will automatically run whenever code is committed or an MR is merged.
Remember how a Pipeline is triggered? A Pipeline is also triggered by committing code or merging an MR! So, what is the relationship between a Pipeline and .gitlab-ci.yml? In fact, .gitlab-ci.yml is used to define 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. Within each job, you can use the stage keyword to specify which stage the job belongs to. The script keyword is the most important part of each job and is required. It represents the commands to be executed by each job.
Recall the relationship between stages and jobs mentioned earlier, and guess the result of running 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 the definition in the stages, the build stage runs before the test stage, so the jobs with stage: build will run first, followed by the jobs with stage: test.
Common Keywords#
Here are some commonly used keywords. For more detailed information, please refer to the official documentation.
stages
Defines the stages. By default, there are three stages: build, test, deploy.
types
An alias for stages.
before_script
Defines the commands to be executed before any job runs.
after_script
Requires GitLab 8.7+ and GitLab Runner 1.2+
Defines the commands to be executed after any job finishes running.
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 variables instead.
cache && Job.cache
Requires GitLab Runner 0.7.0+
Defines the files to be cached. When a job starts, the Runner will delete the files specified in .gitignore. If there are files (e.g., 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 to be run by the job. 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 artifacts (e.g., generated binary files), packaged and sent to GitLab. We can then download these artifacts from the project page in GitLab. Note that artifacts should not be confused with cache.
Translation: English