Gitlab CI/CD Sonar 集成简版
CI/CD介绍
持续集成Continuous Integration（CI）持续交付Continuous Delivery（CD）
gitlab概念
Pipelines
是CI/CD的顶级组件
Pipelines are the top-level component of continuous integration, delivery, and deployment.
Pipelines comprise:
-
Jobs, which define what to do. For example, jobs that compile or test code.
-
Stages, which define when to run the jobs. For example, stages that run tests after stages that compile the code.
同一个阶段的Job可以并行运行
Jobs are executed by runners. Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.
variables
script: - echo "$CI_JOB_STAGE"可以子定义变了，也可以使用gitlab-ci 给我们提供的变量，下面是在我们系统中gitlab-ci.yml中的一段代码，其中就使用了系统配置的变量
sonar-scan-push:
stage: sonar-scan
image: sonarsource/sonar-scanner-cli:latest
script:
- git fetch --unshallow
- sonar-scanner -Dsonar.branch.name=${CI_COMMIT_BRANCH,-$CI_MERGE_REQUEST_TARGET_BRANCH_NAME} -Dsonar.qualitygate.wait=true
dependencies:
- unit-test
自定义变量
For example, if you set the variable below globally (not inside a job), it is used in all executed commands and scripts:
variables:
LS_CMD: 'ls $FLAGS $$TMP_DIR'
FLAGS: '-al'
script:
- 'eval $LS_CMD' # will execute 'ls -al $TMP_DIR'
Environments and deployments
目前公司使用jenkins部署而没有使用gitlab-ci 部署，暂时不讲，但是需要知道gitlab-ci也可以支持多环境的部署
Runners
GitLab CI/CD通过协调器把jobs分配到各个runner上去运行job任务。
比如：job比喻成一个任务：将外卖从商家送到顾客手上。runner就是其中的骑手，最终完成外卖平台（协调器）分配的任务。
In GitLab CI/CD, runners run the code defined in .gitlab-ci.yml. A runner is a lightweight, highly-scalable agent that picks up a CI job through the coordinator API of GitLab CI/CD, runs the job, and sends the result back to the GitLab instance.
Steps
开启gitlab CI/CD
项目的跟目录新增文件.gitlab-ci.yml，如下面官网上的文档
To effectively use GitLab CI/CD, you need:
- A valid
.gitlab-ci.ymlfile present at the root directory of your project. - A runner properly set up.
.gitlab-ci.yml
官方stage顺序：build => test => deploy
我们项目多了sonar-scanner少了deploy，所以顺序调整为build => test => sonar-scanner
image: golang:1.14
stages:
# - config_check
- build
- test
- sonar-scan
#config-ini-check:
# stage: config_check
# script:
# - go run -mod=vendor tools/check_config_consistent.go
unit-test:
stage: test
script:
- cd test && chmod +x run_test.sh && ./run_test.sh
artifacts:
untracked: true
only:
- merge_request
- pushes
sonar-scan-push:
stage: sonar-scan
image: sonarsource/sonar-scanner-cli:latest
script:
- git fetch --unshallow
- sonar-scanner -Dsonar.branch.name=${CI_COMMIT_BRANCH,-$CI_MERGE_REQUEST_TARGET_BRANCH_NAME} -Dsonar.qualitygate.wait=true
dependencies:
- unit-test
tags:
- sonar
sonar-scan-merge:
stage: sonar-scan
image: sonarsource/sonar-scanner-cli:latest
script:
- git fetch --unshallow
- sonar-scanner -Dsonar.qualitygate.wait=true
dependencies:
- unit-test
only:
- merge_request
build-main:
stage: build
script:
- go build -mod=vendor src/main.go
runner
Types of runners
In the GitLab UI there are three types of runners, based on who you want to have access:
- Shared runners are available to all groups and projects in a GitLab instance.
- Group runners are available to all projects and subgroups in a group.
- Specific runners are associated with specific projects. Typically, specific runners are used for one project at a time.
install and register
这块还没有实践，
安装
https://docs.gitlab.com/runner/install/linux-manually.html
-
下载二进制文件以替换GitLab Runner可执行文件。例如：
sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64" -
授予其执行权限：
sudo chmod +x /usr/local/bin/gitlab-runner -
启动服务：
sudo gitlab-runner start
注册
https://docs.gitlab.com/runner/register/index.html
docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
gitlab-runner register \ --non-interactive \ --url "https://gitlab.com" \ --registration-token "$REGISTRATION_TOKEN" \ --template-config /tmp/test-config.template.toml \ --description "gitlab-ce-ruby-2.6" \ --executor "docker" \ --docker-image ruby:2.6
sonar配置
项目工程跟目录的下创建sonar-project.properties
#刚才配置的project key
sonar.projectKey=project-key
#刚才配置的token
sonar.login=token-string
#sonar地址
sonar.host.url=http://xxxxx:9000
#非测试代码的目录，代码会导到sonar, 并基于这些代码做覆盖率统计
sonar.sources=src/biz,src/manager
#测试代码所在目录
sonar.tests=test
sonar.go.exclusions=**/vendor/**,**/*_mock.go
#go test -json > test.out 命令输出的文件
sonar.go.tests.reportPaths=test/test.out
#go test输出的代码覆盖报告文件
sonar.go.coverage.reportPaths=test/coverage.out
Only allow merge requests to be merged if the pipeline succeeds
You can prevent merge requests from being merged if:
- No pipeline ran.
- The pipeline did not succeed.
This works for both:
- GitLab CI/CD pipelines
- Pipelines run from an external CI integration
As a result, disabling GitLab CI/CD pipelines does not disable this feature, as it is possible to use pipelines from external CI providers with this feature. To enable it, you must:
- Navigate to your project’s Settings > General page.
- Expand the Merge requests section.
- In the Merge checks subsection, select the Pipelines must succeed checkbox.
- Press Save for the changes to take effect.
This setting also prevents merge requests from being merged if there is no pipeline. You should be careful to configure CI/CD so that pipelines run for every merge request.