To introduce CI/CD

The emergence of CI(Continuous Integration) and CD(Continuous Delivery/Continuous Deployment) is mainly to help us find bugs in code earlier during development. So we don’t have to build on these bugs (one mistake after another) or even merge them into a QA or staging environment (one mistake after another).

In human terms, when we submit code to Git, Git will automatically build and test the script. If this process fails, we will be notified so that we know that there is a problem with our submitted code. At the same time, the testing process does not require any human intervention (low cost).

CI/CD workflow

  1. Start a new branch
  2. Run automated scripts to build or test our submitted code
  3. code review
  4. Run the automated script to deploy our submitted code

Ci global principle

  1. gitlab-runnerTimed polling (byconfig.tomlthecheck_intervalTo specify the interval)gitlabSpecify the repo
  2. Commit code to the specified branch
  3. gitlab-runnerCode changes detected, executing project.gitlab-ci.ymlThe script defined in

Install gitlab runner

1. Create volumes managed by Docker

 	docker volumes create gitlab-runner
Copy the code
  • If you choose to mount a file directory directly, skip this step
  • Compared with mounting a file directory directly, this method has better portability. For other advantages, please refer to

2. Create and start the Gitlab-Runner container

    docker run -d --name gitlab-runner --restart always \
        -v /var/run/docker.sock:/var/run/docker.sock \
    		-v /bin/docker:/bin/docker \
        -v gitlab-runner-config:/etc/gitlab-runner \
        gitlab/gitlab-runner:latest
Copy the code
  • The first mount is implemented in the container with the hostdockerCommunication (throughcurl)
  • The second mount is implemented within the container in combination with the first mountdocker.sockExecution hostdockerThe command

3. The registered gitlab – runner

    docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register
Copy the code
  1. Fill in theGitLab instance URL. This is oursgitlabThe address of the instance, if it is self-created, is the domain name of the self-created instance, if it is official, is enteredhttps://gitlab.com
  2. Fill in thetoken. Open corresponding project-->settings-->ci/cd-->runners, you can seetoken
  3. Fill in thedescription.This is based on thisrunnerFill in the purpose of “, no special
  4. Fill in thetags.This tag allows us to use the.gitlab-ci.ymlThe configuration determines which commit this timerunnerTo execute the script in the file
  5. chooseexecutor.Well, I choseshell. The purpose is to be able to communicate with the host in the containerdockerCommunication.

4. Some caveats

  1. Due to theciThe script defaults togitlab-runnerThis user executes, and this user is not authorized to accessdocker.sock. So, you need to putdockerAdded to the groupgitlab-runnerIn the subordinate group of. performusermod -aG docker gitlab-runner
  2. If you rely on management pluginsgradle, then usually also needjavaThe environment.

Consider mounting the host’s Java directory and configuring Java environment variables in the container. Docker-compose: apt-get install -y docker-compose

Write. Gitlab – ci. Yml

Let’s start with an example:

stages:
	- build
	- test
	- deploy
job1:
	stage: build
	only: xxx
	tags: defined in gitlab-runner
	before_script: do something
	script: 
	after_script: 
job2:
	stage: test
	allow_failure: true
	only: 
		changes:
			- "xxx.yaml"
job3:
	stage: deploy
	only: 
		refs:
			- main
		changes: 
			- "service-one/*"
Copy the code

1. stages

  • Stages Specifies the stages that a CI job may have. If we do not specify build,test, and deply by default.
  • The order in which they are defined determines the order in which jobs are executed. So when we define jobs that have dependencies, if they correspond to
  • The order of stage itself is the same as the order of dependencies of jobs, so you can omit the definition of dependencies.
  • For example, job2 will be executed after job1, regardless of the order in which jobs are defined, depending on the order in which stages are defined.

2. job

  • Job1 and job2 define two jobs. Job1 is the name of a job.
  • Do not set the job name to a keyword such as “stages”.

3. stage

Specify the stage of the current job. Note that jobs with the same stages can be run in parallel. The parallelism number is set by Concurrent in the config. Toml configuration file of Gitlab-Runner

4. only

And this is what indicates when CI is triggered. For instance,

  • Only is followed by a value (only: XXX), which indicates the branch to be applied to
  • Changes under only indicates where changes (file or directory) trigger CI
  • The subentry refs under only indicates which branch or Mr (with merge_requests) to apply to.

5. tags

Specify the gitlab-runner to execute the script. This tag must be the tag that gitlab-runner registration is filled in

6. allow_failure

Whether job execution failure affects subsequent job execution. The default value is false. True indicates that the failure of the current job will not affect subsequent job execution. False indicates that the failure of the current job will affect the entire pipline of the terminal.

7. before_script,script,after_script

Execution order from front to back. Usage is usually before_script: initializes work script: body script after_script: ends work