05月04, 2017

jenkins小尝试

今天在知乎看到一篇文章:前端开发如何让持续集成/持续部署(CI/CD)跑起来

想到电脑上之前装过一个 jenkins的war包,于是抱着尝试的心态弄了一下。。其实我司构建流程就是用的jenkins,当时我还想着:构建好的目录放在哪里呢?这个答案,其实看一下书,或者认真google一下就出来了。

关于流程的东西,在上文中已经提及了,唯一要说的是gitlab的webhooks那里的url:

http://10.203.131.19:8899/gitlab/build_now

这里10.203.131.19:8899是jenkins的服务器地址,后面的gitlab/build_now是写死的。

jenkins自定义端口号启动

java -jar jenkins.war --httpPort=8899

jenkins后台启动

java -jar jenkins.war  &

后台启动了,肯定后面想把它kill掉,在kill之前只要找到端口号就行:

ls -la | grep jenkins
kill 具体端口号

jenkins的两个目录

config_1

config_2

简单来说,就是两个目录:workspace和jobs

workspace用来存放代码,而jobs则是管理代码的构建历史日志。

jenkins邮件配置

一开始我认为,他会有一个管理员的邮件账号(统一的),然后当构建fail时,会给指定(需要配置)的邮箱发邮件。

事实上不是的,这个管理员的邮件账号(即发送者)是需要自己指定。

web-hook是否真的有意义?

和同事讨论了一下,代码push就触发构建,在我司并不是非常好的方案。一是因为构建慢(build+npm安装,大概需要十分钟左右),二是同事会经常push代码。

当然其实钩子也提供了其他事件的触发,截图如下:

hook

就我司而言,用的是定时构建,感觉这种相对实用一些。当然不同的人,有不同的看法。

jenkins深入

这里深入下去,可以探讨的话题有很多。

比如说jenkins在run build之后,ssh到目标机器,将build里面的成果发送过去。

再比如,发送过去之后,那个项目可能是node project,那么可能需要pm2 restart 某个ID号。

这些都需要写shell脚本。

好心累!!

本文链接:www.my-fe.pub/post/try-jenkins.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。