测试一个hello的pipeline的语法格式
pipeline { agent any stages { stage('Build') { steps { echo "hello" } } stage('test') { steps { echo "hello" } } stage('deploy') { steps { echo "hello" } } } }控制台输出了三个任务，分别执行hello，大概就是这个样子
目录也持久化了，看到新增的jenkins的项目任务
[root@k8s-node3 ~]# ll /ifi/kubernetes/default-jenkins-home-pvc-0d67f7f5-2b31-4dc8-aee2-5e7b9e0e7e19/jobs/
总用量 0
drwxr-xr-x 3 1000 1000 61 1月 13 11:36 test
drwxr-xr-x 3 1000 1000 61 1月 13 14:04 test-demo
jenkins pipeline就像一个管道的建模一样,在这个脚本里完成了整个生命周期各个阶段，从development开发提交代码commit id,到build构建，再到test测试，再到stage步骤做一些处理，deploy部署到dev或者qa环境中，最后到线上,其实在这个流程中它是有一个目的的，刚开始是在开发环境，最终是把它带到线上环境，而中间一系列的流程都是通过管道的形式串起来，而这个管道这个模型是通过pipeline去书写的，这个语法就是这个模型，需要把这个生命周期的所需的都套进这个模型中来，然后由jenkins pipeline去管理
第一用这个pipepine它有很大的特点
1、可视化页面，每个步骤都可以可视化展示，方便我们去解决每个步骤的相关问题
2、每个步骤都写脚本里面了，只需要维护这个脚本就好了，而这个脚本可以写的具有通用性，如果想写多个项目时，比如发布3组微服务，那么第一个写的pipeline，那么也同样适用于第二个和第三个微服务的模版。那么这个需要考虑它们有哪些不同点？
不同点：
1）拉取git代码的地址不一样
2）分支名也不一样，因为是不同的git地址，所以打的分支名也不一样。
3）部署的机器也不一样，有可能这几个服务部署在node1,另外的服务部署在node2或者node3
4）打出的包名不一样
所以要把这些不同点，做成一种人工交互的形式去发布，这样的话这个脚本才具有通用性，发布服务才能使用这写好的pipeline发布更多的微服务，而且jenkins pipeline支持参数化构建。
这里也就是pipeline一些的语法，比如选择parameters参数化构建，选择框式参数choice parameter，比如给它几个值，然后让它动态的去输入，或者凭据参数credentials parameter,或者文件参数file parameter，或者密码参数password parameter，或者运行参数 run parameter,或者字符串参数 string paramether ,或者多行字符串参数multi-line string parameter,或者布尔型参数boolean parameter
比如选择choice parameter，选择型参数
比如发布的git地址不一样，那么就需要多个地址可以去选择，需要使用choice parameter选择框型参数，这个可以体现在构建的页面，也可以体现在configure配置的页面,这样配置也比较麻烦，所以直接在configure里面直接添加对应的参数就可以
先配置一个看一下效果
将生成的选择型参数添加到指定的pipeline的语法中，save一下
再回到项目中可以看到build名字从build now换成了build with parameters，也就是增加了几行的的配置，可以进行选择的去拉去哪个分支下的代码了
也可以在configure去配置，这两个地方都可以添加，要是再添加一个直接add parameter，可以选择多种类型的参数帮助我们去构建这个多样式的需求
再比如分支这一块，可能每次打的分支都不同，这个不是固定的，所以需要一个git的参数化构建，那么这个就需要动态的去从选择的git地址获取到当前的所有的分支
还有一个分布的机器不同，这个也可以使用刚才的choice parameter，将多个主机的ip也进去