RT-Thread-【开源之夏2023】聊⼀聊开源之夏以及项目的进展（rt-thread上用CI来验证软件包的编译情况）RT-Thread问答社区

【开源之夏2023】聊⼀聊开源之夏以及项目的进展（rt-thread上用CI来验证软件包的编译情况）

发布于 2023-08-24 16:23:05 浏览：613 订阅该版

[tocm]

# 前言

### 开源之夏是什么

⾸先来简单介绍⼀下开源之夏。

开源之夏是开源软件供应链点亮计划下的⼀个暑期活动，由中国科学院软件研究所与 openEuler社区联合主办，旨在⿎励在校学⽣积极参与开源软件的开发维护，促进优秀 开源软件社区的蓬勃发展。

活动联合各⼤开源社区，针对开源项⽬的开发与维护提供 mini 任务，开放给全球⾼校 学⽣报名申请。学⽣可⾃主选择感兴趣的项⽬进⾏申请，并在中选后获得社区资深开 发者亲⾃指导的机会。项⽬成功结项并贡献给社区后，参与者将获得开源之夏活动奖 ⾦和结项证书。

学⽣可⾃主选择感兴趣的项⽬进⾏申请，中选后在项⽬开发者（社区导师）的指导下 进⾏开发。根据项⽬的难易程度和完成情况，结项者将获取开源之夏活动奖⾦和结项 证书。 
开源之夏官⽹：https://summer-ospp.ac.cn/
### 我参与开源之夏的⼀些契机

⾸先介绍⼀下我的情况，我是⼀名研究⽣，今年的下半年就要找⼯作。⼀般来说应该在这个暑期找⼀份实习，来为后⾯的找⼯作做准备，但是很可惜，因为某些不可抗⼒，我⽆法实现这⼀计划。
不过这个时候我有同学给我分享了开源之夏（在这⾥我要⾮常感谢分享给我这个活动的同学）。由于开源活动、开源实习基本是全程线上，适合因为某些原因⽆法实习的同学参与，刚刚好可以稍微替代⼀下暑期实习。

### 开源之夏的申请过程

RT-Thread 算是最早⼀批的加⼊开源之夏的社区，在⽹络上也可以搜到前⼏年的开源
之夏相关的信息。

今年的开源之夏RT-Thread社区同样也准备不少可选的项⽬。

在这个⻚⾯可以看到RT-Thread社区今年的项⽬列表。

https://summer-ospp.ac.cn/org/orgdetail/8bce77cd-7c54-48b8-a3e6-f816338692cb

我选择的项⽬是：rt-thread上⽤CI来验证软件包的编译情况（基础）

对于主流和常⽤的软件包，添加CI编译机制，结合官⽅给出的 pkgs-test，构建⼀个CI机器⼈，能够在master提交和修改代码的 时候，能够知道哪些软件包编译不过，并且能够⽣成编译结果报 告，并且将⼀些可以在qemu上运⾏的⼀些程序在qemu上运⾏并 且输出结果。先以qemu-vexpress-a9为基准测试软件包

因为我在之前刚好⽤过CI⼯具测试过zepherRTOS的项⽬，因此我看到这个就⻢上添加到待选列表⾥⾯了。
开源之夏的申请⽅法是需要提交项⽬的申请书和个⼈简历（申请书在开源之夏⽹站上会有模版提供）。于是我在了解整个项⽬过后完成了这两份材料。
完成材料之后，我根据导师的联系⽅式，向导师提供了申请书并根据项⽬的⼀些内容介绍了⾃⼰的相关经验，⼤概确定了意向（其实这⾥我看了项⽬仓库的fork和star感觉没有其他⼈申请，因此我就没有再准备申请其他的项⽬）。
在项⽬确定下来之后我就开始进⾏开源之夏的活动了。

# 项目内容

仓库主⻚ https://github.com/RT-Thread/pkgs-test

### 项目介绍

官⽹的项⽬说明可以在这⾥查看
https://summer-ospp.ac.cn/org/prodetail/238bc0128

关于这个项⽬⾸先需要了解⼀下什么是RT-Thread的软件包，RT-Thread软件包是运⾏在RT-Thread系统上⾯的⼀套通⽤的代码库。相当于提供了很多模块，⽐如各种外设的驱动、⼯具等等，只要使⽤的是RT-Thread操作系统，就都可以导⼊并使⽤。RTThread软件包和RT-Thread操作系统⼀样是⼀个开源的平台，任何⼈都可以制作⾃⼰的软件包，也可以去帮助维护别⼈的软件包。

因为这种⾃由、开放的特性，软件包社区⾥⾯会遇到某些软件包⽆法使⽤、不能编译通过的问题。
- 版本迭代造成的编译问题（内核⽂件改动后，软件包没有去做版本控制）
- 架构冲突以及 bsp 依赖问题（某些软件包只在特定的架构或 bsp 中可⽤）
因此需要⼀个⼯具来暴露出社区软件包的相关编译问题。

### 使用场景

下⾯是软件包测试⼯具的使⽤场景。
1. 本地使用

A. 对特定的软件包，在⼀些指定的bsp、rt-thread版本上进⾏测试。

B. 指定某⼀个特定的版本或所有版本。

C. 指定的软件包集合。

2. 作为Github Action使⽤，测试软件包是否⽀持⼀些rtt版本和bsp。
a. 软件包开发者

i 软件包测试：更新软件包的代码之后，⾃动对软件包进⾏测试。

ii rt-thread的master测试：定时对软件包进⾏测试，检查是否⽀持rt-thread的master版本。

b. rt-thread社区维护⼈员

i 所有软件包测试：定时对全部软件包在master 分⽀或指定的⼀些版本上进⾏测试，并发布测试结果到github pages。

ii 软件包索引更新测试：软件包索引发⽣改动时，对改动的部分软件包进⾏测试，在github pages上面更新这部分测试结果。

iii rt-thread版本发布测试：rt-thread版本发布后对全部的软件包进⾏测试。

iv 精品软件包集合测试（TODO）：对⼀些制定的精品软件包集合进⾏测试，⽐如当rt-thread的master分⽀改动时，测试这些软件包。

对于⼀些更具体的介绍，可以来看这⼀篇⽂章。

https://club.rt-thread.org/ask/article/9c05fc7fcc0223fe.html

# 项目工作
我在接⼿这个项⽬的时候，已经完成了本地测试的使⽤和软件包索引仓库使⽤的⼀些

基本功能，我是在此基础上进⾏开发的。

截止到目前，我完成的内容⼤概如下：

- 将测试的⼀些参数（如内核版本，测试的bsp等）通过程序运⾏的参数传⼊。之前是通过修改配置⽂件来实现的，如果是作为ci⼯具使⽤不是很⽅便。

- 将软件包的测试结果⽣成json并发布到github pages，主要是提供⼀个获取软件包可⽤性的⽅式。完成了对新旧测试结果的合并，以及上传冲突的解决⽅案。

https://rt-thread.github.io/packages/pkgs_res.json

- 从json⽣成了⼀个html⻚⾯也发布到了github pages，这⾥原来是有⼀个html报告的，主要是从直接⽣成html改成了从json⽣成，然后增加了测试时有每个版本有多少个软件包通过了测试等信息。

https://rt-thread.github.io/packages/

- 然后就是在软件包索引仓库添加了这个⼯具，完成了定期对全部软件包进⾏测试。

接下来主要的⼯作，就是去在RT-Thread仓库⾥⾯去集成这个⼯具，对rt-thread仓库的每次代码在⼀些精选的套装软体上⾯进⾏测试。以及去完善⼀下⾃动测试后的回响，每次测试结果都不是很⽅便查看，需要通过actions⾃动在pr⾥⾯回复相关的⼀些信息，让开发者能够更⽅便的了解到哪⾥出了问题，为什么没通过检查。