Original link: https://editor.leonh.space/2022/gitlab-ci/
GitLab CI is GitLab’s CI service. This article shares the usage of GitLab CI and how to write the configuration file .gitlab-ci.yml.
CI is the abbreviation of continuous integration. It is called continuous integration or continuous integration in Chinese. It is usually mixed with continuous delivery and continuous deployment. Some people call these DevOps. The overlapping rate of meanings is really too high, and I secretly think that constantly inventing new terms and new interpretations is not helpful for understanding these things, so we return to the basics and call it CI, because its pronunciation is simpler than DevOps, and it is not like those two. The CD classmates’ association is named after the CD in life, so let’s call it CI!
Continuous Integration…what?
What is CI, I try to explain it in one sentence – ” automatic operation after submitting code “.
Automated operations usually include three major steps – construction, testing, and deployment. How to do these three tasks is defined by the descriptions in .gitlab-ci.yml in GitLab’s case.
The above is a minimalist CI explanation.
Why do CI?
Because the current mainstream development idea in the information industry is continuous improvement , which means the release of new versions in small steps and rapid iterations, the purpose is to shorten the time to market time, but the side effect is that each small change requires a lot of manpower to build The work of setup, testing, and deployment, so we began to try to automate these three tasks.
The establishment of the continuous improvement model originated from a work model of rapid process improvement that was born in the United States during World War II to meet the military needs at that time, and was carried forward in Japan after the war . In Taiwan, many manufacturing industries with Japanese backgrounds have also maintained continuous improvement. Improved working mode.
GitLab CI
As mentioned earlier, the work of GitLab CI is defined in the .gitlab-ci.yml file, and the machine that performs these tasks is called runner. The runner is usually a virtual machine, and the runner can be built by itself or using GitLab.com Provided shared runners, you can see these runners in the CI/CD settings page of the GitLab project:
The code or name of these runners is not important, the important thing is those blue tags, these tags mark the characteristics of a runner, for example, we will use Windows later, then we will specify in .gitlab-ci.yml there are windows tag runner to perform CI work.
Stage & Job & Pipeline
The three major tasks of CI mentioned above—build, test, and deploy are called stages in the term of GitLab CI. There is a logical sequence relationship between these stages. The test is run when the build is successful, and the deployment is done when the test is successful. This kind of relationship is called pipeline in GitLab CI, and the above picture is the pipeline in a GitLab project, it will be automatically generated according to the configuration of the project’s .gitlab-ci.yml, and it is quite intuitive to let us see at a glance Know the current CI status.
Stage is the unit of the CI stage, and does not define the actual instructions to be executed. The specific instructions to be executed are defined in the unit called job. In the above figure, there are build-job and test stage in the build stage. Then there are two jobs, and so on.
The runner mentioned above is the executor of the job. It should be noted that the runner of each job is independent. Without special configuration, there is no shared file and other resources with each other, and after a job ends, its runner also Then it is eliminated, and finally we are left with only the runner running job status, log and other information, which should be paid special attention to when writing .gitlab-ci.yml.
.gitlab-ci.yml
.gitlab-ci.yml is used by GitLab CI to define several concepts mentioned above – stage, job, etc. It is the soul of the entire GitLab CI. If you have ever written Dockerfile, docker-coompose.yml or other provisioning configuration files Friends, seeing .gitlab-ci.yml should appear familiar disgust Feel.
Because I just want to build a small toy under Windows at the moment, so here we demonstrate the configuration based on Windows runner.
We use the GitLab Windows shared runner , and some development tools have been pre-installed for us in the machine. The commonly used C++ compilation tools, .NET Runtime, etc. have been pre-installed.
The Windows runner is slightly different from the commonly used Linux runner:
- The command environment for Windows runner is PowerShell.
- In GitLab Windows shared runner, one of the pre-installed tools is Chocolatey , which is a package management tool in the Windows world. We can use Chocolatey to help us install the necessary programs in the CLI environment.
- Windows runner is not a Docker container, so cannot specify
imageandservicesin .gitlab-ci.yml.
Refer to the following example as the starting point for our .gitlab-ci.yml universe:
stages : - build - test - deploy default : tags : - windows before_script : - Set-Variable -Name "time" -Value (date -Format "%H:%m") - echo ${time} - echo "started by ${GITLAB_USER_NAME}" build-job : stage : build script : - echo "running scripts in the build job" test-job1 : stage : test script : - echo "running scripts in the test job 1" test-job2 : stage : test script : - echo "running scripts in the test job 2" deploy-job : stage : deploy script : - echo "running scripts in the deploy job"
From the concepts mentioned above, the first one is the stages block, which defines three stages: build , test , and deploy . Their order also determines the order of CI operations, so what you see in pipline is also It would be the order build > test > deploy.
The second largest block, default , defines the default values for subsequent jobs. First, tags are used to specify the runner of the job. For this example, the runner must have a windows tag to execute the job.
Then we focus on the before_script block. As the name suggests, the commands in before_script will be executed before each job’s own commands. Generally, before_script will be used to install development tools, etc. For example, there is no pre-installed Python in GitLab Windows shared runner, so For a Python project, each job must install Python first. In such an example, the command to install Python will be written in the before_script block, for example:
default : tags : - windows before_script : - choco install python --yes --version 3.9.6 - $env:Path = "C:\Python39\;C:\Python39\Scripts\;" + $env:Path - python -m pip install --upgrade pip
The project in default can be replaced in the job. For example, in the build-job I want to specify a specific version of Windows, then I can set its tags in the build-job separately:
build-job : stage : build tags : windows-1809 script : - echo "running scripts in the build job"
For the next four jobs, the script block inside defines the command to be executed by the job, which depends on each project and performs itself. This will be a process full of try and error, and I wish you good luck.
Although the content of this .gitlab-ci.yml is very bright at present, we can still play and feel it. Put .gitlab-ci.yml in the project folder, commit and push it to GitLab, open the browser and enter On GitLab’s project page, you should be able to see the execution status of these jobs on the CI/CD page, and you can also click to see the job log. They are working hard for us:
Running with gitlab-runner 14.0.0 (3b6f852e) on windows-shared-runners-manager 6QgxEPvR Preparing the "custom" executor Using Custom executor with driver autoscaler 0.1.0 (495ee7a)... Creating virtual machine for the job...
The above is the basic usage of GitLab CI.
Epilogue
This article only introduces the most popular usage and configuration methods of GitLab CI. It can also meet 80% of the needs of ordinary people. It is much easier to get started than looking at the files of several units in the original factory. If it helps you, Please help me to like, subscribe, and turn on the little bell.
Finally, see < Keyword reference for the .gitlab-ci.yml file > for the complete .gitlab-ci.yml syntax.
This article is reprinted from: https://editor.leonh.space/2022/gitlab-ci/
This site is for inclusion only, and the copyright belongs to the original author.