认识openEuler-Advisor

• 1. WHAT
• 2. WHERE
• 3. WHY
  • 3.1. 肉眼可见的关系
  • 3.2. 传说中的关系
    • 3.2.1. 批量建仓
    • 3.2.2. 软件包自动升级
• 4. WHEN
  • 4.1. 写仓库下的yaml文件时
  • 4.2. 试图获取上游仓库信息时
• 5. HOW
  • 5.1. 怎样开发

1. WHAT

openEuler-Advisor字面意思可以理解为openEuler的软件顾问， 它的目标是为openEuler制品仓的日常工作提供自动化的巡检和建议。

2. WHERE

openEuler-Advisor的仓库在哪里呢？

• 开发源码在openeuler中：https://gitee.com/openeuler/openEuler-Advisor
• rpm源码在src-openeuler中：https://gitee.com/src-openeuler/openEuler-Advisor

3. WHY

我们为什么要认识openEuler-Advisor呢？它是一个自动化巡检工具，跟我们有什么关系？

3.1. 肉眼可见的关系

1. 仓库缺少spec文件的issue
   

2. 仓库source url无法访问的issue
   

3. 仓库缺少yaml文件和source无法溯源的issue
   这里有没有发现什么问题？

4. 软件升级到最新版的issue
   

5. spec文件中source url中的宏无法解析的issue
   
   https://gitee.com/src-openeuler/clamav/blob/master/clamav.spec
   
   
   https://gitee.com/src-openeuler/kf5-karchive/blob/master/kf5-karchive.spec
   

6. repo地址重复的issue
   

7. openeuler/community中仓库sig组变更PR的审视清单
   

8. PR中的abi检测
   

可能还有别的可见我未见的，这些都是openEuler-Advisor这家伙搞得。

3.2. 传说中的关系

什么是传说中的关系？就是：只听说没见过，但逻辑上肯定有的一种关系。
翻译成人话，就是：相关任务都被别人做了，没落到我头上，所以跟我没关系。

3.2.1. 批量建仓

只听说过建仓是往openeuler/community中提交建仓PR，其它的就不清楚了。

实际上这里的建仓PR，只是一种建仓申请，告诉openeuler需建哪些仓库。

那具体是怎么来填写这些仓库信息呢？答案是通过两种yaml配置文件：repository配置文件和sigs配置文件。

1. repository配置文件
   https://gitee.com/openeuler/community/tree/master/repository
   repository配置文件分为：openeuler.yaml 和 src-openeuler.yaml 两个文件。
   这两个配置文件管理了整个 openEuler 开源项目中所有代码仓的元数据信息，指导社区自动化工具对这些代码仓的管理。
2. sigs配置文件
   https://gitee.com/openeuler/community/tree/master/sig
   sigs配置文件分为：sigs.yaml和sig-info.yaml两类文件。
   openEuler试图通过SIG将软件包进行分门别类，所以新建的仓库自然就要划分到相应的SIG中，主要修改sigs.yaml文件。
   备注：当前sig-info.yaml还在完善中，应该是用每个sig-xxx目录下的README暂代了

说了这么多，openEuler-Advisor到底是如何批量建仓的呢？
上面介绍的repository和sigs两种配置文件，如果软件包的数量很多话，通过手动修改这两个配置文件，将是一件糟糕透顶的事情。
openEuler-Advisor批量建仓的功能就是批量自动化的修改这两种配置文件。

举个建仓申请的例子：
这是新建一个仓库的PR：https://gitee.com/openeuler/community/pulls/1567 修改情况如下：

3.2.2. 软件包自动升级

软件包自动升级是指自动化完成一个软件包的升级工作，敲完一条升级命令，就可以去喝茶了，不苟颜笑中……

不好意思，搞错了，重来！

这里的软件包自动升级是一种简单的升级，还是需要人边喝茶边干预的。
主要包括：下载推荐版本源码包、简单修改spec、本地obs编译、创建PR及issue等。

像下面这些情况，是需要您干预，甚至重来的：

• 源码包下载失败
• 版本差异大，历史patch打不上的
• 版本差异大，打包时，文件或多或少或改名的
• 版本差异大，spec中那些零碎的小修小改错误的
• 版本差异大，依赖关系发生变化的
• ……

凌乱在风中……

4. WHEN

你讲了这么多，openEuler-Advisor好像还真和我们有很大的关系，那你说吧，我们什么时候要去认识认识它？

除了上面提到的关系，当我们碰到的时候，需要去认识它。其实还有一些隐藏的，也值得我们去认识它。

4.1. 写仓库下的yaml文件时

目前应该要求每个仓库下（最起码master分支下），应该有一个yaml文件，包含其上游仓库信息，目的是指导自动化工具做软件升级、补丁跟踪等。
上图截取自openEuler-Advisor的README

4.2. 试图获取上游仓库信息时

openEuler-Advisor中提供对接码云开放API的实现类gitee.py，基于它进行扩展，可以实现一些满足我们需要的小功能。比如：批量删除个人账号下多余的仓库，获取指定仓下的spec文件或yaml文件，批量检测PR是否编译成功，批量检测PR是否合入等等。

其实，在写仓库yaml文件的时候，你会发现version_control存在多种版本控制协议，为什么没有gitee呢？
这也可能是因为很多软件不是国人写的，我想说的不是这个，既然码云提供了开放API，那么别的托管平台是否也有开放API，或是别的有用的信息呢？

举几个例子：

• pyporter基于pypi的包管理json文件，完成了python包的自动引入的大部分工作。
• oa_upgradable基于仓库yaml文件，可以获取大部分仓库的版本列表（tag信息）

再看一个例子：
问题：这是一个在做软件包升级时碰到的问题，就是统计每个软件包当前版本和最新版本，及其相应的发布日期，当时是人工一个一个仓库查找的，大部分是github上的仓库。
思考：版本发布一般会用tag标记，获取了tag信息，某种程度上也等于是获取了版本列表。github上的仓库，通过git命令可以很方便获取其tag及对应的commit ID列表，但是发布时间却获取不到。

通过这仅有的commit ID怎么能获取对应的提交时间呢？一个方法是把仓库clone到本地，通过查询log信息，根据commit ID过滤出对应的提交记录。

实际上，github也有开放API，通过commit ID可以获取一条提交记录的详细信息。

参考链接：https://docs.github.com/en/rest/reference

那么，其它托管平台呢？我想可能也存在着某种方式，让我们可以得偿所愿……

5. HOW

这里我不想谈openEuler-Advisor该怎么做，openEuler-Advisor该怎样改进是一个不断迭代的过程，是需要付诸行动的。

我想谈谈怎么做开发，可能很多人没有真正开发过，换句话说就是没怎么写过代码，我觉得谈谈这个意义可能更大一些。

5.1. 怎样开发

先看下一个简单的开发流程：

需求从哪里来？

• 外部：客户、市场、甲方……
• 内部：想法，需要……

从需求的内部来源可以看到，只要你需要，只要你有想法都可以把它变成一个需求，然后按照上面的流程，把它实现。当然需求的大小，会决定实现的难度，但这不意味着需求只能大，而不能小。

看一个例子：
如何查找一个软件包是属于哪个SIG的？

需求：如何快速获取一个软件包的SIG
需求理解：SIG（Special Interest Group特别兴趣小组，简称 SIG），openEuler每个软件包都会被划分到相应的SIG中，记录在sigs.yml文件中……
设计：用哪种语言开发（shell，python…），实现流程……
开发：编码
测试：开发自测，测试团队测，用户使用……