项目中配置触发构建
点开高级,配置token
点击生成,保存
然后是gitlab的配置
项目settings下,Webhooks,点击新增,URL 就是jenkins上提示的url 如下图, Secret token就是jenkins点击生成的token,copy过来就好了
然后就可以点击测试了
成功以后会有提示
git也会触发构建
Over!打开CMD命令提示符输入页面,输入修改指令:
修改好了可以在cmd中输入指令,敲击回车后,不会有其他提示,则代表修改成功。
也可以到自己的项目中提交一次代码
测试中文名是否修改成功'
修改好了可以在cmd中输入指令,敲击回车后,不会有其他提示,则代表修改成功。gitlab-ci全称是gitlab continuous integration的意思,也就是持续集成。中心思想是当每一次push到gitlab的时候,都会触发一次脚本执行,然后脚本的内容包括了测试,编译,部署等一系列自定义的内容。本文就是利用gitlab-ci的持续集成来实现自动部署。相比之前 webhook的自动部署 还是强大以及方便了许多。
自动部署涉及了若干个角色,主要介绍如下
这样就装好了gitlab-ci-multi-runner,然而我们只是装好了gitlab-runner,当然我们要接着向gitlab-CI注册这个runner,不然gitlab-CI在push事件到来的时候怎么知道要调用谁呢?这里也可以发现和webhook方式的区别,webhook方式是我们主动配置了一个连接给gitlab;gitlab-runner只要注册一下就好了。
那么我们就注册一下
然后就注册好了,在gitlab中相应的位置就可以看到你注册好的runner信息。
这里我们只有一个stage是deploy。only指定了只有在master分支push的时候才会被执行。tags是shell,对应了刚才注册runner的时候的tags。
最重要的script部分deploy Example_Group Example_Project,这里是一条shell指令,为了方便通用性,deploy是我在服务器上编写的一个脚本,传入参数是Example_Group Example_Project分别是项目组名和项目名。执行这一条指令就能够自动部署到/xxx/Example_Group/Example_Project的服务器目录下。那么随便什么项目都用这个格式去套就好了,这样新项目的自动部署也不需要登录到服务器上去修改了。
并编辑成如下内容
这个脚本的大意就是,如果目录不存在,那么就git clone一个,如果存在了就git pull一个到指定目录下。这样就达到了自动部署的目的。记得修改里面的gitlabexamplecom的地址哦。
加上执行权限,然后把这个脚本放在gitlab-runner的~/local/bin下就可以生效了(为了不用写难看的/deploy)
并且把 /local/bin加到$PATH路径中(用户执行命令时候能够查找到这个目录),只要在 /profile末尾加入这一句话
用cat查看公钥,然后复制这一串公钥。在gitlab中新建一个账号比如叫gitlab-runner,把这个账号添加到你的项目成员中,然后在这个账号的user_profile里面,把公钥粘贴进去就好了。总之就是把这个账号配置成能用ssh登录的。
如果还是不成功,可以在服务器上手工deploy XX XX一次,第一次访问这个服务器的时候,有个命令行提示是要把sign添加进已知服务器列表,需要手工输入个yes。如果在服务器上能够正常deploy,那么
这样就大功告成了。
尝试一下git push到相应项目,然后到服务器上的目录看一下是不是有了呢。
GitLab-CI与GitLab-Runner
GitLab官方材料1,安装gitlab,参考:[ >进入JENKINS_HOME目录,找到configxml文件,找到了和节点。节点代表是否使用用户权限,节点代表用户权限是怎么划分的。
下面提供2种方法:
1、恢复默认设置
直接删除和节点
2、配置管理员权限
这种方法适用于已经存在一堆的权限,重新配置麻烦。
在节点中添加内容如下:
hudsonmodelHudsonAdminister:anonymous
hudsonmodelHudsonConfigureUpdateCenter:anonymous
hudsonmodelHudsonRead:anonymous
hudsonmodelHudsonRunScripts:anonymous
hudsonmodelHudsonUploadPlugins:anonymous
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)