RT-Thread-[github][action] RTT CI机器人优化之道RT-Thread问答社区

[github][action] RTT CI机器人优化之道

发布于 2023-04-02 00:10:35 浏览：514 订阅该版

[tocm]

## 简介
本文主要讲述如何处理github action消耗时间过长的问题.目前已经将action从20分钟优化到6分钟左右
之前其实官方的issue上有相关的issue.
https://github.com/RT-Thread/rt-thread/issues/5969
主要是觉得github 的action 的编译时间太慢了.
看到有很多小伙伴想了很多妙招,但是看上去时间还是很长.
有位小伙伴就想到了用镜像的方式,先把环境搭好.这个其实github有个推荐的标准的方式,叫package.这个后续有机会分享给大家.
但是这位小伙伴辛苦做完之后,发现作用不大,提速不明显.

也有小伙伴想到了,把bsp拆出去,也有想到了一个机器里面检测N次build

在这里,要郑重的感谢这些小伙伴提供的IDEA. 我觉得应该对我有所启发.
## 简单分析流程

我很喜欢马斯克的"第一性原理"
在此引用一下

01什么是「第一性原理」思维？其实是一种演绎法思维
追本溯源。首先，最早提出这个概念的是亚里士多德**，他说：“在任何一个系统中，存在第一性原理，是一个最基本的命题或假设，不能被省略，也不能被违反。”**

这个哲学概念很深。但是，我们理解他提出这个概念背后的机理就够了。**那是为了解释我们生活中所看见的各种现象。他认为任何事物的存在，任何现象的发生，都不是无缘无故的，其背后一定存在一个本质原因。**

这次的问题很简单:
action的CI编译时间过长.
之前都是差不多20分钟左右,(其实这个已经很短了,想象一下bsp里面有几百个CI要检测).
我们来看下ACTION的时间大部分花在哪里了.

从过往的action 来看:

单独编译完成一个bsp,大概需要2分钟.
一共差不多200多个bsp.而如果都是一个CPU在跑的话,差不多要400分钟.

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20230401/3c5e6940b923730cc4f327b816f6beb6.png.webp)

但是我们的action只用了20分钟.已经了不起了. 很明显,这里action采用了多线程并行的方式执行.

但是一个bsp只需要2分钟不到,如果所有bsp都并行的话,那时间也不应该20分钟这么多呀.

所以真相只有一个, **并行的线程数不是无限制的**

那就很简单了,解决这个时间问题的话,核心矛盾并不在环境搭建上,而是在这个并行的线程数上.

仔细研究了一下action每次并行的数量,差不多在10个左右. 我们假设每次10个线程,搭建环境和编译最快计算1分钟.一共是200个bsp.  200/10 * 1 = 20 分钟. 刚好吻合.

所以解决问题的首要原则:
1. BSP环境的搭建并行的任务不宜超过太多.正常10个左右即可.
2. 每次环境搭建可以多编译几个同系列的bsp
3. 每个toolchain环境不一样,可以把同一个toolchain的bsp放到一起去.

## 如何处理
有了这个思路之后,我们其实处理起来应该会简单一些. 不过说实话,对于一个平时编程语言不是yml的工程师来说,这个其实有些难度.不过我们始终相信,方法总比困难多.在请教高人的指点下,我们一步一步的实现我们想要做的事情.

首先第一点就是:   matrix是用来区分每个task的,但是如何能够放一个数组在每个task里面并且进行轮询呢? 具体如何实现的,大家可以参考这个PR.
https://github.com/RT-Thread/rt-thread/pull/7140

这个其实告诉答案之后, 可能看起来比较简单一些.
但是,说实话,这个也是试验了很多次才试验出来的(大概100多次吧). 其实感觉不是天天写这些yml的,确实会遇到各种奇怪的问题.

优化之后,每次CI的时间差不多在4分钟~6分钟左右,相较于20分钟,还是有一些提升的.感觉以后再也不用等太久的CI了.

## 建议
其实这里PR的分组,由于需要均匀的在各个toolchain上排布,所以在分组的时候,没有考虑太周全.
如果大家对bsp感兴趣的话,可以考虑帮每个分组起个合适的名称.还有一些arm的bsp分组可能不太合理,你可以根据编译时间和各个系列的bsp,将这些bsp合理分配. 仅限于sourcery-arm.
参考链接
https://github.com/RT-Thread/rt-thread/blob/master/bsp/README.md

## 想说的

其实写这篇想要表达的其实也很简单. 就是有一些很简单的想法,可能会能帮助到开源RTTHREAD很多,提升一些效率. 还有就是,不要担心你的PR没有技术含量.其实有时候,开源RTTHREAD,也需要一些小伙伴帮忙处理一些简单的任务,毕竟人力和精力都有限的,如果你发现了小问题,你会的,可以尝试PR帮忙解决,说不定能帮上大忙.
团队协作才是正道.

# 大家可以PR的时候试试看，是不是CI的速度快了一些呢？欢迎反馈