是
生成每个组件的临时版本号（规则为目标分支版本号.JOBID，比如4.12.0.115），根据组件的dependencies字段构建的顺序进行打包伙伴系统生成临时版本号之后，比如有A\\B\\C三个组件，组件临时版本号为A-0\\B-0\\C-0，第一个先构建A，将A-0传入，A打包成功之后，将A的临时版本号和B的临时版本号带入B的构建中，当前组件版本号用COMPONENT_VERSION字段（新增，原来是项目自己读取），他所依赖的组件以及版本号用DEPENDENCIES字段，这个逻辑目前就有；以此类推。如果中间有一个组件构建失败，则整个链路打包终止，临时版本号作废
无
初始状态：待审核
合并本次集成包含的所有MR
Android | IOS通用流程
全部组件构建成功？
IOS无本次操作
创建需求
阻塞队列是否为空？
弹窗确认：有集成失败，是否继续发布
IOS流程
否
报错，当前MR不可合并，不做任何处理
MR合并成功
集成列表是否有集成中状态
仅检测上次发布到本次发布之间的记录
结束
将各个组件的最新版本号修改到目标版本的依赖列表中
向审核人和需求成员发送钉钉通知，告知集成成功
发布
激活审核列表的重试按钮
报警：有集成中的申请，请处理之后再发布
集成列表是否有集成失败状态
提交测试包
重新发起提交测试包
通过/重试
Queue.poll根据先进先出规则拿出第一个元素
将各个组件仓库的目标分支上打上${组件名}-VERSION-${版本号}的TAG
给每个组件的源分支执行git命令git pull origin ${目标分支} -rgit push -frebase目标分支远端代码
驳回
目前是否有正在执行的任务
开始集成打包【基于源分支打包】
发布成功
申请集成
允许集成
如果存在该文件，将所有组件的临时版本号写入到组件目标分支仓库里面的/${组件名}/version.properties文件中的version属性中，不存在该文件，则跳过
Git执行成功
构建安装包
是否包含组件
状态修改为集成失败，显示失败原因
向审核人和需求成员发送钉钉通知，告知失败原因
否，MR保持原状
检测集成包含的MR全部是否为正常可合并状态，包含Pipeline已经通过
加入阻塞队列
比如4.12.0版本cpnt-square集成成功，将4.12.0版本中的cpnt-square的依赖版本从原来的版本修改为刚刚打包成功的版本，operator为集成自${需求ID}需求，如果当前版本属于灰度阶段，修改依赖列表也不需要审核，直接通过，所以依赖修改那边需要判断来自于集成的修改，来自于集成就直接放过，修改成功
合并主工程MR到目标分支
状态变更为集成中
不通过
Android流程
状态变成排队中
状态变成已集成
发布流程校验
丢弃该任务
开始执行该任务
重新申请集成
有
