jenkins使用

以前在给一些开源项目贡献代码的时候，在 github 上一提交 pull request 或者提交的分支代码更新了的时候， jenkins 就会自动把代码进行 merge 并且运行单元测试，当时看了心里就2个字： NB！ 那个时候心里就想，啥时候我也得弄这么一个高大上的玩意儿。随着 gitlab 在工作中的逐渐使用，这个想法越来越强烈。上周末搜来搜去，发现jenkins还真有一款针对gitlab的 merge request 的插件： Gitlab Merge Request Builder Plugin 当时就心痒难耐，开始看着说明一步步的配置。配置分成2大部分： 第一部分： 安装插件&基础设置 首先安装插件，要求jenkins版本大于 1.563 ，好在jenkins升级比较方便，在 系统管理 界面就有个大大的升级按钮，果断升级到 1.570 。 在 系统管理 -> 插件管理 -> 可选插件 里面搜出来 Gitlab Merge Request Builder 安装并重启 jenkins，官方文档在这里强调了需要 重启jenkins 。 重启之后,进入 系统管理 -> 系统设置 里面，能发现里里面多了 Gitlab Merge Request Builder 的配置项 Gitlab Host URL 里填gitlab的服务地址，比如 http://192.168.0.1

持续集成和部署是DevOps的重要组成部分，Jenkins是一款非常流行的持续集成和部署工具，最近试验了一下Jenkins，发现它是我一段时间以来用过的工具中最复杂的。一个可能的原因是它需要与各种其它工具集成才能完成任务，而集成的方法又各不相同。在这些工具中，Docker是最简单的，真的非常好用。K8s比较复杂，开始要花些时间熟悉，但它的整体设计十分合理，一旦搞清核心概念，掌握脉络之后，就非常顺利。它的命令格式即规范又统一，使得有些命令自己都能猜出来，这就是好的设计带来的福利。。但Jenkins给人的感觉就是开始的时候没有设计得很好，后面在不断地打补丁，导致一件事情有好几种不同的做法，对不熟悉的人来讲无所适从。没有统一的风格，处处都是意外，使得整个系统看起来既庞杂又没有章法，当然这也跟它出来的时间比较长有关。虽然它可能不是最好的，但它是免费的，因此不能要求太高。 由于种种原因，我的Jenkins安装碰到了各种各样的问题，为此我查看了大量的资料。但遗憾的是每个人安装Jenkins的方法都有些不同，很难找到一篇文章能解决所有问题。在我看来，Jenkins的安装有两三个关键之处，非常容易出错，一定要理解透彻才能成功。 本文分成两部分，第一部分讲正常安装步骤，如果一切顺利，就不需要看第二部分了。我只能说恭喜你，你的运气太好了。第二部分是讲各种问题及解决办法，这应该是本文最有价值的部分。

最近学习Docker与Jenkins, 网上大部分都是关于Jenkins+Git+Docker进行持续远程部署, 我一直在考虑为什么Jenkins和Docker要绑定一块使用, 因为我想单独使用Jenkins进行本地构建然后远程部署, 那么这就开始行动. 准备Linux服务器 我在Azure创建了一台CentOS7服务器, 开放22端口供SSH使用, 并且开放了5000和5001端口. 安装DotNet Core 基于微软官方文档, SSH到服务器使用如下命令安装: sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm sudo yum install dotnet-sdk-3.0 配置Jenkins Jenkins的安装请参考我的之前的一篇博文, 在此基础上, 我们安装如下插件: Publish over SSH 安装完成之后配置相关参数: Manage Jenkins -> Configure System 去配置SSH服务器的参数. 同时还需要添加环境变量允许本地执行dotnet, 首先输出本地所有环境变量: echo $PATH 然后以输出内容为值, 以Path为键, 添加到Global properties -> Environment

本文转载于: 猿2048 网站➭ https://www.mk2048.com/blog/blog.php?id=hcaijch2jb 一、背景 在日常开发中，我们经常会有发布需求，而且还会遇到各种环境，比如：线上环境（Online），模拟环境（Staging），开发环境（Dev）等。最简单的就是手动构建、上传服务器，但这种方式太过于繁琐，使用持续集成可以完美地解决这个问题，推荐了解一下 Jenkins 。 Jenkins构建也有很多种方式，现在使用比较多的是自由风格的软件项目（Jenkins构建的一种方式，会结合SCM和构建系统来构建你的项目，甚至可以构建软件以外的系统）的方式。针对单个项目的简单构建，这种方式已经足够了，但是针对多个类似且又存在差异的项目，就难以满足要求，否则就需要大量的job来支持，这就存在，一个小的变动，就需要修改很多个job的情况，难以维护。我们团队之前就存在这样的问题。 目前，我们团队主要负责开发和维护多个Android项目，而且每个项目都需要构建，每个构建流程非常类似但又存在一定的差异。比如构建的流程大概如下： 克隆代码； 静态代码检查（可选）； 单元测试（可选）； 编译打包APK或者热补丁； APK分析，获取版本号（VersionCode），包的Hash值（apkhash）等； 加固； 上传测试分发平台； 存档（可选）； 触发自动化测试（可选）；

前言 前面已经有介绍sonar的安装，简单应用，下面在简答的研究一下sonar和jenkins集成的简单使用，对于sonar的安装不做介绍 一 sonar的简单介绍 持续检查避免了低质量的代码，比如SonarQube工具就能够帮助我们完成此项。每次代码提交后，在代码上就会执行代码分析。 分析是基于代码分析工具中定义的一些规则，如果代码通过了错误阀值，那么它会允许到生命周期的下一步，如果超过了设定的阀值，那么直接返回错误。 SonarQube是代码质量管理工具，允许团队去管理，追踪和改善他们的源代码质量，它是包含了规则，告警和阀值的一个基于WEB的应用。它包含了七种类型的代码质量参数，分别是加构和设计，重复，单元测试，复杂度，潜在bug，编码规则和评论。 SoanrQube是一个开源的工具，支持几乎所有的流行语言，并且能够和CI工具有效的集成执行持续检查。 目前已经有的工具 Jenkins：192.168.132.131 Gitlab：192.168.132.132 Sonar：192.168.132.133 Artifactory：192.168.132.134 二 配置sonar 2.1 生成token 生成一个token，这个token是sonar和Jenkins连接的钥匙 生成token token

　　Jenkins 是一个可扩展的持续集成引擎。 主要用于： 　　持续、自动地构建/测试软件项目。 　　监控一些定时执行的任务。 　　Jenkins的安装： 上传jdk 和jenkins 的rpm 包到服务器直接使用yum 安装即可 # yum localinstall jdk-8u131-linux-x64_.rpm jenkins-2.138.4-1.1.noarch.rpm yum安装完成之后，我们将jenkins设置为开机自启动，并启动 systemctl enable jenkins systemctl start jenkins jenkins启动之后我们关闭防火墙 systemctl stop firewalld setenforce 0 jenkins的默认端口为：8080 然后我们可以在网页中输入http://192.168.11.136:8080 看到上面的页面时，我们需要在服务器中使用 cat 查看 /var/lib/jenkins/secrets/initialAdminPassword 中的密码 蓝线标注为密码，将上面cat 获取的密码输入到网页中 之后选择安装的插件后就完成了 Jenkins安装包官方下载地址： https://pkg.jenkins.io/redhat-stable/ Jenkins安装官方手册： https://jenkins.io

前戏 我们使用docker --help来查看下都有哪些命令 [root@docker ~]# docker --help Usage: docker [OPTIONS] COMMAND [arg...] docker daemon [ --help | ... ] docker [ --help | -v | --version ] A self-sufficient runtime for containers. Options: --config=~/.docker Location of client config files #客户端配置文件的位置 -D, --debug=false Enable debug mode #启用Debug调试模式 -H, --host=[] Daemon socket(s) to connect to #守护进程的套接字（Socket）连接 -h, --help=false Print usage #打印使用 -l, --log-level=info Set the logging level #设置日志级别 --tls=false Use TLS; implied by--tlsverify # --tlscacert=~/.docker/ca.pem Trust certs signed only by this CA

在jenkins后使用html publisher查看html报告时，发现显示不全，很多东西显示不了。 在查看官方文档后，这原来是安全问题所导致的。 Jenkins安全默认是将以下功能都关闭了 1、javascript 2、html上的内置插件 3、内置css或从其它站的css 4、从其它站的图处 5、AJAX 我的网页使用的是css，所以显示不全。解决方法如下： 在jenkins系统管理中输入以下脚本运行： System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")如下图： ------> 再次查看，显示正确 注意： 此方法只适用于 HTML Publisher Plugin to version 1.10以上的版本 原文链接： https://www.iteye.com/blog/myeyeofjava-2324110 来源： https://www.cnblogs.com/longronglang/p/11778572.html

本文转载于: 猿2048 网站➤ https://www.mk2048.com/blog/blog.php?id=h0kajk0ijb 前期准备 liunx 基本命令 git 基本命令 nginx jenkins 工具 github 账号和项目 git centos 服务器 坐稳啦！ 要发车啦！ 首先登录你远程服务器地址 输入远程服务器地址 ssh 用户名@远程服务器 ip 地址 首次登录有提示信息 输入 yes 就好了 登录成功！ 安装nginx nginx -v //输入查看 说明服务器没有安装 nginx yum install nginx //输入下载 or yum install epel-release //如果上一步安装失败 yum install nginx //再次下载 y //回车 安装完毕！ nginx -v nginx 已经安装完毕 修改nginx配置 nginx -t //查看配置文件地址 cd /etc/nginx ls //可以看到 nginx.conf 配置文件 vim nginx.conf or yum install vim //如果没有可以安装vim 再次执行上步 vim 编辑器用法 i //编辑器底部出现 insert 后 你可以编辑配置文件了； 修改配置 user 改成 root (服务器用户名 我的是 root)

我使用的是docker部署jenkins，使用172.16.1.245作为部署服务器。 1.问题 在SSH Publishers里执行的环境变量，不是ssh server主机设置的环境变量，这样会导致某些通过SSH Publishers执行的程序因为环境变量不同而执行错误。 2.实际案例 例如我们在172.16.1.245机器设置环境变量LD_LIBRARY_PATH 2.1设置LD_LIBRARY_PATH 2.1.1先设置/etc/profile vi /etc/profile 使设置生效 source /etc/profile 2.1.2再设置root/.bash_profile vi ~/.bash_profile ~代表当前用户目录，例如root用户~等同于root，所以上面命令等同于 vi root/.bash_profile 使设置生效 source ~/.bash_profile 2.1.3检查设置是否生效 echo $LD_LIBRARY_PATH 经过检查LD_LIBRARY_PATH环境变量与设置的一致 2.2通过jenkins的SSH Publishers查看环境变量LD_LIBRARY_PATH 2.2.1新建job，选择“创建一个自由风格的软件项目” 2.2.2在“构建”里选择“Send files or execute commands over