（后期添加：
这篇博客是在刚研究并发构建时写的，所以方法比较老套，采用的时流水线（pipeline）的方式,实现时通过如果job的用户配置来创建多个新的执行任务的job，并且将执行日志回收到入口job，任务执行结束后删除job，基本上是采用jenkins api来创建job–>执行job–>删除job，这样的方法比较麻烦，并且不直观。但是如果你想了解jenkins api如何实现流水线来仿照并发构建过程，你可以参考下这篇博客~~
后面资料看多了，也手动操作多了，发现并发构建有更加简单的办法，请参考我的另外一篇博客：https://www.cnblogs.com/zndxall/p/8516189.html
）
可以参考对应的API，下面是关于我的任务场景的不同jenkins内置命令的使用。
任务1：实现多用户同时触发任务
分析：常见情况是我们只需要一个人触发jenkins出包给其它人用，但是如果想结合个人构建，那么明显一个任务多个人触发时，必须要等上一次构建结束，才能开始下一次的构建，因为只有一个任务入口，举个例子，比如一个餐厅，只有一个服务员一张餐桌，只能容下一个客人，那么其它客人就必须排队，等这个客人吃完了，多用户的模式就是有一个点单员和多个服务员和多张桌子，客人只要告诉点单员，接下来就有其它服务员来一对一服务你，不会像第一种情况那样，完全卡在一个人。
方法：还是要保持有一个job做入口，但是这个job的用时要尽量控制到最短，然后下发任务到其它下游job执行，下游job的特点就是要跟用户相关，能够标识用户。我的步骤：
1.入口job主要的任务是获取当前是哪个用户触发的，以及该次触发的num是多少，并保存用的配置；
需要的插件’user build vars plugin’ 在任务配置中勾选如下：
然后使用如下命令就可以获取到user和num
echo jenkins var as follow:
echo build_num=$BUILD_NUMBER
echo build_user=$BUILD_USER
2.创建一个模板任务，根据自己的需要做好设置，目的主要是为了获取一个简单标准的config.xml文件，后面要用到，我的模板任务设置如下：
处理上面1的设置，还有就是执行脚本的设置，其中上面的“sh /usr/local/scripts/build_scripts/build_mode.sh build_branch push_action build_channel build_tvar build_code build_job ”这一窜随便写，里面对应的build_mode.sh实际也是不存在的，这串会被记录在job的config.xml中，后面我会用自己实际的脚本名来替换，马上你就可以看到了。
3.（1）在入口job，比如mul_user作为入口job,在mul_user的job调用curl -u admin:123456 $jenkins_url/job/Build_Template/config.xml -o config.xml -v 获取模板Build_Template的config.xml，（-o 后面的是下载到本地的文件名）参考我上面的模板配置，这个config.xml文件如下，我只截取了我需要改动的部分，就是构建部分，就是步骤2的那段字符串sh /usr/local/scripts/build_scripts/build_mode.sh build_branch push_action build_channel build_tvar build_code build_job，然后根据自己的需要修改这个本地的这个config.xml中的构建字段，我的修改如下：
sed -i ‘s/build_mode/push_tag/g’ config.xml
sed -i s/build_branch/$1/g config.xml
sed -i s/push_action/$2/g config.xml
sed -i s/build_channel/$3/g config.xml
sed -i s/build_tvar/$4/g config.xml
sed -i s/build_code/$build_module/g config.xml
sed -i s/build_job/$build_name/g config.xml
（2）使用curl -u admin:123456 -X POST $jenkins_url/createItem?name=$build_name -d @config.xml -H “Content-Type: text/xml” 创建一个新的任务，其中build_name，我使用的是$user_$name_模块的组合，能够唯一表示是哪个用户的哪次的哪个模块的构建，再看@config.xml 说明我们需要依赖这个配置文件，才能生成新的job,由于这个config.xml文件是来自于我们事先设置的模板的模板文件，所以这个新的job和模板job的结构是一样的，除了那串构建被替换成了我们需要的脚本。
（3）使用curl -u admin:123456 -X POST $jenkins_url/job/$build_name/build 来触发新的job的构建，到此，入口job mul_user的任务就完成了，我自己的设置发现，十几秒这个入口job就结束了，触发构建后，下游job会自己跑起来。
4.在下游job跑完以后，调用curl -u admin:123456 -X POST $jenkins_url/job/$6/doDelete 来删除刚才新建的job,这个动作可以在新建job中调用脚本是实现。
由于任务删除后，新建的job构建日志就看不到了，所以建议将步骤2的模板job的构建阶段修改为sh /usr/local/scripts/build_scripts/build_mode.sh build_branch push_action build_channel build_tvar build_code build_job |tee console_log，使用tee 命令 将log保存下来，然后存放到其它位置，方便出错时检查问题。
任务2：修改job的config.xm后不重启服务生效
描述：有时候，我们的构建是带参数构建的，但是参数内容会经常有变化，就需要手动去修改参数，比如某一个模块的代码经常会迁分支，也会合入主线，每次有新的分支增加的时候就需要去界面配置，有分支合入的时候，又要去界面删除，这样很麻烦。
分析：既然界面的配置都会被保存在任务的$jenkins_path/jobs/$job/config.xml文件中，那么只要修改这个config.xml文件就可以了。
难点：发现，修改了这个文件以后，再去刷jenkins界面，修改并没有生效，查资料说，需要重启服务器才能生效，重启后果然生效了，但是这并不使用，有没什么方法不需要重启就能生效呢。
解决：使用jenkins的内置命令reload即可，命令为：curl -u admin:1234456 -X POST $jenkins_url/$job_name/reload 。
这样，不需要重启就能生效。
