git绑定gitlab账号_gitlab注册用户

大家好，我是讯享网，大家多多关注。

在项目开发过程中，为了保证代码质量，我们会使用很多代码质量检测工具，这些工具要么在本地，要么在云端。虽然工具可以检测异常问题，但这些问题仍然需要我们的程序员来修复。如果不强制所有人修复异常问题，有些人可能会跳过异常检测，把代码放到主干里。为了解决这个问题，我们需要一个强制访问控制系统。所谓访问控制，是指访问控制只能通过测试才能访问，而访问控制不通过测试是不能访问的。GitLab本身就给我们提供了这样的设置，我们只需要配置好检测规则就可以了。

开启代码合入门禁

在项目设置中，配置只允许管道的成功合并请求。

GitLab Runner

要实现流水线的执行，当然需要执行过程和执行环境。GitLab为我们提供了一个CI工具——git lab Runner。通过配置GitLab Runner，我们可以在GitLab上注册环境。当代码提交后，GitLab可以使用执行环境来运行我们的检测功能。

下载安装

虽然也可以通过docker安装，但是GitLab Runner只是一个二进制文件，下载后可以直接在机器上运行。而且如果使用docker进行部署，执行命令也在docker中，如果需要一些其他的环境配置，就必须安装在docker中，比较麻烦。

https://git lab-runner-downloads . S3 . Amazon AWS . com/latest/binaries/git lab-runner-Linux-amd64

#将下载的文件复制到/usr/local/bin目录下的mv gitlab-runner-Linux-amd64/usr/bin/gitlab-runner #增加执行权限chmod +x gitlab-runner#生成配置gitlab-runner install-user = root-working-directory =/data/git lab-Runner #启动服务git lab-Runner启动注册服务安装git lab后，需要在git lab上注册GitLab Runner，可以选择如何共享Runner，指定Runner。Shared Runner是我们的管理员账户获得的全局注册信息。注册后，这个Runner可以被所有代码库使用。指定的运行器是为每个仓库配置的特定运行器，只能运行该仓库的管道。我建议你注册一个共享跑者，因为一个共享跑者也可以设置成多个代码库的跑者，比较方便。

使用管理员账号登录Git Lab后台

注册共享Runner

gitlab-runner register

url令牌和URL令牌如上图所示。请输入描述并标记您自己。记住标签，以后再用。

查看Runner注册是否成功

启动Runner服务

#这是一个在前台运行的命令，需要nohup转换成后端运行。#还有人说sudo注册的GitLab-runner是直接运行gitlab-runner运行后台测试GitLab管道创建。gitlab-ci.yml在项目根目录下创建一个. gitlab-ci.yml文件，其内容可以配置如下:

阶段:-sonarchecksonarcheck:阶段:sonarcheck脚本:-echo $ ci _ project _ dir-CD $ ci _ project _ dir-sonar-scanner标记:-sonarstages:指定管道的所有步骤。

脚本:当前步骤的执行命令。

$CI_PROJECT_DIR:默认的环境变量，在执行这个管道的过程中下载的代码目录。

标签:使用的流道

如果您想查看所有内置的环境变量，您可以按如下方式配置它们

脚本:-export//在Linux下使用此命令-& # 39；导演环境:& # 39；Windows用这个命令提交代码后，会看到管道自动执行。

对接sonarqube

gitlab管道配置好之后，我们就可以对接sonarqube实现代码访问控制了。

搭建sonarqube环境

请参考我们上一篇文章:构建sonarqube代码质量扫描环境。

配置门禁关联

这一块花了我很长时间，网上也找不到相应的教程。在我最终放弃之前，我终于完成了。本来我的想法是，大家在给骨干提交MR的时候就要开始流水线。如果装配线通过，它将运行并关闭。如果装配线没有通过，它就不能关闭。基于这个想法，我很久都没有意识到。最后我意识到GitLab中配置的“只允许合并管道成功的合并请求”是指在合并请求中，如果管道成功，就会被允许。这里我们提交MR的时候不运行管道，但是当我们运行管道之后提交MR的时候，GitLab会得到这个关闭对应的管道状态。如果状态为成功，则允许关闭，否则不允许关闭。所以我最后配置了每次提交都运行管道任务，这样在关闭的时候就能正确获取状态，防止关闭不成功。

配置流水线任务

在项目根目录下创建一个. GitLab-ci.yml文件，这样GitLab在提交时会自动检测这个文件的配置，并根据配置运行任务。这里不详细描述文件的配置。网上有很多类似的文章，我们一般用的都比较简单。主要逻辑在脚本中实现。

stages:-sonar check-check result variables:access _ token:xxxx secret:xxxx check _ path:/data/xxxx/sonar data PROJECT:xxxx sonar check:stage:sonar check脚本:-echo $ CI _ PROJECT _ DIR-CD $ CI _ PROJECT _ DIR-sonar-scanner标记:- sonarcheckresult: stag E: check结果脚本:-CD $ check _ path-python 3 sonar . py $ PROJECT $ access _ token $ secret标记:-sonar stages:配置执行阶段。如果不配置，会有几个默认阶段。变量:配置变量。Sonarcheck/checkresult:这是任务的名称，可以随意启动。我这里用的是和舞台一样的名字。阶段:用于指定当前任务对应哪个阶段。脚本:任务执行命令。标签:当前任务需要运行到哪个Runner？跑步者的标签在这里配置。仅:配置执行分支、条件等。如果不进行配置，所有分支将在提交时运行任务$CI_PROJECT_DIR。这是在此任务中下载的代码路径。这是一个环境变量，您可以用上面描述的方式承诺所有的结果检测脚本。因为我们使用sonar cube进行代码质量检测，Runner执行的sonar-scanner只是调用sonar cube扫描命令，不会收到成功或失败的结果。所以即使sonar cube检测到的代码有问题，管道也不会报错，所以我们需要自己写代码来检测sonar cube是否检测到异常，如果有就抛出错误。

从sonarqube导入系统从dingtalkchatbot导入声纳qubeint。chatbot导入dingtalkchatbot，卡项，动作卡#获取声纳qube def getsonar qubeinfo的测试结果(branch = & # 34主人& # 34；，component=None，url=None，username=None，password = None):sonar = sonarqube client(sonar cube _ URL = URL)sonar . auth . authenticate _ user(log in = username，username=username，password = password)component _ data = sonar . measures . get _ component _ with _ specified _ measures(component = component，branch=branch，fields = & # 34指标，周期& # 34；，# metricKeys = & # 34″”# code _ smokes，bug，coverage，duplicated_lines_density，ncloc，# security_rating，reliability_rating，vulnerabilities，comment_lines_density，# ncloc_language_distribution，alert_status，sqale _ rating # & # 34″”metricKeys = & # 34代码_气味、错误、漏洞& # 34；)component_data中的result _ dict = { } for info _ dict[& # 34；组件& # 34；][“措施& # 34；]:result _ dict[info _ dict[& # 34；公制& # 34；]]= info _ dict[& # 34；价值& # 34；] return result_dict#发送钉钉消息通知此异常结果def send _ ding _ msg (access _ token，secret，result_dict，project，URL):web hook = f & # 39；https://oapi.dingtalk.com/robot/send?访问令牌= {访问令牌} & # 39；chatbot = dingtalchatbot(web hook，secret = secret)btns =[car item(title = & # 34；查看详情& # 34；，url = f & # 34{ URL }/项目/问题？id = { project } & resolved = false & # 34；)]action card = action card(title = & # 39；亲爱的，这个修改有问题！！！’，text = f & # 39测试结果如下:\ n \ nbug:{ result _ dict[& # 34；臭虫& # 34；]} \ n \ n脆弱性:{ result _ dict[& # 34；漏洞& # 34；]} \ n \ no dor:{ result _ dict[& # 34；code _ smokes & # 34；]}’，btns=btns，btn_orientation=1，hide _ avatar = 1)chatbot . send _ action _ card(action card)if _ _ name _ _ = = & # 39；_ _ main _ _ & # 39:url = & # 34http://192 . 168 . 1 . 123:9000 & # 34；用户名= & # 34；管理& # 34；密码= & # 34；123456″branch = & # 39主人& # 39；project = sys . argv[1]access _ token = sys . argv[2]secret = sys . argv[3]sonar cube _ data = getSonarqubeInfo(branch = branch，component=project，url=url，username=username，password = password)if(sonar cube _ data[& # 39；臭虫& # 39；] != 0)或(sonar cube _ data[& # 39；漏洞& # 39；] != 0)或(sonar cube _ data[& # 39；code _ smokes & # 39；] != 0):打印(& # 39；代码检测异常:& # 39；，sonar cube _ data)send _丁丁_msg(access_token=access_token，secret=secret，result _ dict = sonarqube _ data，project=project，URL = URL)sys . exit(1)else:print(& # 39；这个投稿太完美了！完美& # 39；)写好脚本后，我们把它放到执行机上。上不上图书馆，看个人需求。我们的目标是在sonarqube执行之后运行这个脚本。

测试门禁效果

我使用的访问控制配置如下:

阶段:-sonar check-check result-build-deploy变量:access _ token:xxxxx secret:xxxxx check _ path:/data/xxxxx/sonar data项目:xxxxx deploy_path: /data/xxxxx/ frontendsonarcheck:stage:sonar check脚本:-echo $ CI _ PROJECT _ DIR-CD $ CI _ PROJECT _ DIR-sonar-scanner标签:-sonar except:-master check result:ST age:check result脚本:-CD $ check _ path-python 3 sonar . py $ PROJECT $ access _ token $ secret标签:-sonar except:-master build:stage:build脚本:- cd $CI_PROJECT_DIR – yarn – yarn构建标签:- sonar only: -仅声纳:-主缓存:paths:-dist/deploy:stage:deploy脚本:-RM-RF $ deploy _ path/*-CD $ CI _ secret

sonarcheck

在非主分支下，执行声纳扫描检查。

checkresult

在非主分支下，执行sonar.py脚本，获取sonarqube检测结果。

build

在master分支下，进行前端打包，然后缓存dist目录。

deploy

在主分支下，构建任务只有在成功执行后才能执行。将上一步缓存的内容下载到dist/目录下，清空空前端部署目录，然后将dist目录下打包的文件复制到前端部署目录下。

提交代码启动流水线任务

当我们提交代码时，管道任务被触发。

单击管道任务以查看执行阶段。

如果要查看特定的执行日志，可以单击特定的阶段进行查看。

当执行完成时，可以提交关闭请求。

提交合入请求

您可以看到管道任务的状态将显示在关闭请求中。当管道任务尚未完成时，您将看到以下界面

管道执行完成后，将显示以下界面:

如果管道执行失败，则不能点击merge按钮，从而确保每个合并都必须通过检查。因为我们已经配置了主分支包部署，所以当合并代码时，包部署管道将自动启动。

执行打包部署

总结

在配置的过程中，有一些问题需要了解，比如Runner的配置，CI文件的配置。在配置CI文件时，应注意缓存处理。默认情况下，每个执行阶段都会将环境清理到最干净的状态，即所有生成的中间文件或修改过的文件都会在下一个执行阶段之前恢复到与Git仓库同步的状态。针对这种情况，CI为我们提供了一种缓存机制，分为本地缓存和服务器缓存。服务器缓存主要用来解决分布式管道执行，一般本地缓存就够了。本地缓存将在本地生成缓存目录。如果我们想在某个阶段缓存文件或目录，我们可以在某个阶段配置缓存。当然，也可以全局配置，这样缓存对每个阶段都有效。在我们的示例中，只配置了缓存路径path，因此所有管道都将被缓存在一个目录中。如果每个分支需要缓存不同的文件，就需要添加key的配置。除了键的配置，还有缓存策略的配置。默认的策略是下载/上传，但是在某些任务中，我们只需要使用前一阶段的缓存文件，所以我们可以将其配置为拉策略，这样只下载前一步的缓存文件，而不会上传到。

设置sonarqube代码质量扫描环境