用Jira webhook和Jenkins创建自动审批工作流
由于工作的原因，需要写一个自动审批的工作流，看了下网上的分享，资料不多；经过几天的踩坑，决定写这篇分享，不对之处欢迎指正
首先创建一个工作流
Manage Jenkins - Manage Plugin - JIRA Trigger Plugin
Manage Jenkins - Configure System - JIRA Trigger Configuration
完成前面两部之后，开始创建webhook
Jira - 系统 - 高级 - webhook 点击右上角创建webhook
保存之后，在浏览器输入刚刚webhook的URL，回车后如果提示这是一个POST请求
则表示webhook设置成功了！
总结一下webhook的工作原理：
也就是创建流水线的job，随便命名后，看到Build Triggers
其实到这里，整个webhook就可以用了，改变某个issue到指定状态，此job应当是会自动构建的，如果没有自动构建，那么要么是URL写错，要么是状态变更的错误，具体问题具体分析了。
前面说到webhook发起的是POST请求，很有意思的一件事请就是参数是如何传的呢？
webhook页面，URL下面写了可以在URL中使用下面的额外变量，我以为只要点击某个变量，加到URL后，即可传递此参数，可是事实是加上参数后URL甚至都不能用了。
不知道是不是我使用的姿势有问题，看了很多网上的分享，我了解到webhook的URL被请求后，实际上是默认会传issue的key过去的，我们选择一个已经构建的job rebuild一次，可以看到确实传了参数issue key
那么其实其他的参数都是没有用的么？
也许是有用的，可能是我引用的参数不对，目前为止，我只发现不传参的时候URL是可以被自动调用的（欢迎指正）
可是这个issue key其实已经足够有用了，你可以通过调jira的api获得你想要的信息，下一篇讲如何在pipline中使用参数
jenkins 更改工作空间
win10、Jenkins、JDK_1.8、tomcat
由于在Jenkins中我们需要对自己构建的项目进行维护，为了维护方便起见，我们一般都会指定一个自己的目录作为Jenkins的工作空间目录，但是Jenkins与其它软件不太一样的地方在于，其修改工作空间目录并不是在Jenkins本身的配置文件中进行，而是在电脑操作系统的环境变量中进行的。而Jenkins所做的操作是显示该工作空间目录的所在位置，如果工作空间位置被修改了的话，那么它显示的就是修改之后的新的工作空间目录。
查找Jenkins工作空间目录显示位置：
在【系统管理】页面点击【系统设置】进入系统设置页面![jenkins更改工作空间2.png( )
Jenkins的在查找工作空间时是这样运行的，Jenkins默认的内置工作空间为系统用户的根目录下，其文件夹名称为“.jenkins”，比如说我的，其工作空间目录显示的就是“C:\Users\HP.jenkins”，而Jenkins默认的查找顺序是先是在操作系统的环境变量中查找名为“JENKINS_HOME”的环境变量，如果存在该变量，那么Jenkins就采用“JENKINS_HOME”中所指定的目录作为工作空间目录，但是我们在初次装好Jenkins时我们是没有配置“JENKINS_HOME”环境变量的，所以说Jenkins在找不到配置的“JENKINS_HOME”环境变量时就采用了默认的环境变量配置，所以说它才会在“C:\Users\HP.jenkins”中创建工作空间。
依照上面的原理，我们修改Jenkins的工作空间，其实就是在电脑的环境变量中创建一个“JENKINS_HOME”环境变量，在该变量中我们指定Jenkins的工作空间目录即可。
以我的电脑为例，在我的电脑中创建环境变量是这样的：
右击【我的电脑】图标，在鼠标右键所显示的下拉菜单中选择【属性】，由此我们进入【属性】面板。
在该对话框中，变量名为“JENKINS_HOME”，注意，此变量名不能被修改，变量值为“F:\Dev\WorkSpace\Jenkins”，该变量值可以自定义，填写完之后，点击【确定】按钮。
该界面就是我们之前所操作过的解锁Jenkins的界面，但是与之前所不同的是，其新的解锁密码位于新指定的工作空间目录下。
后面的操作我在之前的章节中有介绍，具体可以参考前面的章节
Win10安装Jenkins
再次查看Jenkins的工作空间目录如下：
Jenkins自动化发布方法
jenkins自动化发布首先需要知道其原理，知道了理论后才可以更好的配置。同时也需要知道一些基本知识（如果不懂需要自己学习），比如webhook、docker、宿主主机、挂载目录/文件（外挂仓库）、shell脚本等。
一、前期准备
1、分支
确保自动化发布仓库分支统一，正式环境需要是release，内网测试环境test_release。如果没有的请先新建好。
注：release需要是保护分支，因为正式环境不允许随意发布。设置后需要在保护分支设置里面配置其【可合并 Pull Request 成员】为可以审核发布人。如下saas中台前端的配置：