sssssssssnake的博客

勾选Build periodically， 在Schedule 中填写触发时间。配置定时任务之后，run 一下job，几秒后将job 停掉，使定时配置生效。填写完Schedule 可查看下方的提示确认触发时间。在jenkinsfile 中添加trigger的配置。方法一：（推荐）Pipeline中配置定时。H 3 * * * (每天凌晨三点触发)H 0 * * 7 (每周日0点触发)注： 第一位必须要是 H。点击Configure。方法二：页面配置定时。

根据分支名判断需要调用哪个子流程编译，如果提交是master分支就会到dev/目录下运行master.jenkinsfile。在子流程中配置key 初始化repo 和下载代码 获取patch 命令都已封装成函数写在脚本中,只需传递参数使用。例如：master.jenkinsfile、develop.jenkinsfile。dev目录下 ${Branch_name}.jenkinsfile。Gerrit-code-review 多分支流水线。主流程:Jenkinsfile。Jenkinsfile 模板。

git log --color --no-decorate --decorate 是否显示tag, branch。git log --oneline --left-right --cherry-mark A…git merge --ff (允许fastfoward合并,默认，自动） --no-ff（不允许）git log --merges --no-merges 只显示/不显示 合并节点。git blame -C -C -C 追踪所有commit中从其它文件拷贝过来的行。

配置完成后到仓库下 git remote -v 验证, push地址要指向target 仓库。url 是 target 仓库，pushInsteadOf 是原始 仓库。在~/.gitconfig中添加如下配置。git checkout 推代码到target。

使用下列的Coverity 模板，可完成在 Jenkins 上的Coverity 全量扫描、上传全量报告到服务器端。修改模板Jenkinsfile。

需要在代码仓库配置webhook，需要maintianer权限。webhook配置可以参考Mr 触发的pre build。模板功能用于发版本到gallery上面。

如果配置Scan时间为1min，那么每1min会扫描所配置的代码仓库的分支，如果在该分支上搜索到了配置的Jenkinsfile，就会在Jenkins 创建一个以分支命名的Job并编译，如下图dev，当分支上有新的提交也会触发编译。配置Jenkins job ，调用代码仓库中的Jump Jenkinsfile Jenkins job调用代码仓库中的Jenkinsfile。因多分支流水线 job 以分支为命名，ph rule不能直接触发，所以会创建一个中转的jump job来根据分支下发编译需求。

使用Webhook在推送代码或创建Issue时触发一个事前配置好的URL，GitLab会向设定的Webhook的URL发送一个POST请求。Jenkinsfile 名：Jenkinsfile_Pre_build_MR。https://:@ci.hobot.cc/project/配置Jenkins job ，调用代码仓库中的Jenkinsfile。配置完webhookurl后，勾选Trigger选项，如下图中的2.语句的作用参考 // 后的注释，标黄部分必须根据项目实际情况修改。

此模板可用于下载代码、编译。

可以将外部的/etc/localtime文件在pod启动的时候挂载到docker内部即可。

用来阻止多个构建在同一时间试图使用同一个资源。这里的资源可能是一个节点、一个代理节点、一组节点或代理节点的集合，或者仅仅是一个用于上锁的名字。如果指定的资源没有在全局配置中定义，那么它将会被自动地添加到系统中。quantity：允许运行数量。Jenkinsfile配置。

allure在流水线中的语法可以点击Jenkins job configure最后的Pipline Syntax 查看。在pytest运行函数或命令行中添加： --aullure 后面加上一个路径，用来存放生成的allure 配置信息。Allure-pytest 用来在pytest执行结束后生成allure所需的配置信息。如需在CICD流程中使用，要在docker images中安装allure。这里说的本地环境是指本地开发机或 需要编译生成报告的环境。安装allure-pytest。

prepare docker是参考容器，请根据实际需要设置资源保护的编译docker name去设置，例如：build，ubuntu-build等等编译容器，prepare只是拉代码的容器不用设置保护。最小占用资源和最大占用资源设置成一样值的话，就是docker在启动时会占用固定的资源。最小占用资源和最大占用资源设置成一样值的话，就是docker在启动时会占用固定的资源。设置了资源保护之后，可以最大限度的防止由于资源不足导致的docker 退出的问题。资源设置针对的是pod内的docker容器。

在确认k8s环境的CI集群已经有对应的存储目录之后，需要该目录映射到jenkins job的pod中。cache和gradle缓存目录需要在k8s环境的CI集群的node节点中先创建。当前jenkins 环境已经挂载了一个测试的gpfs目录作为各种缓存目录使用。以下内容针对把k8s pod作为agent的jenkins job场景。这个目录可以是gpfs存储也可以是k8s 集群的node的本地目录。Job 的pod是每次运行的时候会自动挂载。需要设置ccache缓存目录。需要设置gradle缓存目录。

关键字：buildWithParameters。test_param2 pipeline参考。test_param pipeline参考。拥有可运行job权限的用户token。可运行的jenkins job。调用不带参数的job。

如果不用label，直接用node name 也可以调度，写法一摸一样的，就是将label对应的值配置成node name。当前的CI集群配置的策略是 job运行的时候会启动一个pod，等job运行结束会销毁这个pod。Jenkins 通过插件和k8s集群关联，可以通过声明pod的模板，在k8s集群中创建pod。Jenkins 工作模式是master/slave模式，slave端可以是多平台多环境的。程序在运行的时候就会调度到这个demo_node这个标签对应的node节点上面。

方案一： 获取到新增文件列表后，如果本地已有缓存，可以直接进行cov-build,cov-analyze等，因为缓存机制，只会对改动文件相关的代码进行编译，扫描出来的结果也只会是参与编译的文件相关的问题。方案二：由于需要一次全量扫描并上传到coverity后台，利用缓存机制会造成非全量代码参与编译扫描，从而影响coverity后台数据的准确性，所以在做第一次全量扫描上传时候不太适合缓存机制。增量扫描是针对于单次改动的代码，根据改动后的代码，Coverity扫描得到与增量代码相关的一系列问题。

manifest仓库存放不同分支对应的jenkinsfile，master.jenkinsfile、develop。根据分支获取对应manifest.xml下载代码。每个仓库的提交触发对应的多分支流水线，多分支流水线会创建以 change_name 命名的Pre build Job。编译时将判断本次提交patch 的仓库是否在manifest.xml内，不在则退出编译，在则开始更新代码并开始编译。MANIFEST_XML：manifest的命名，例如：manifest.xml 、default.xml。