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

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

发布于 2023-08-09 15:34:04 浏览：464 订阅该版

[tocm]

# 前言

## 开源之夏是什么

首先来简单介绍一下开源之夏。

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

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

学生可自主选择感兴趣的项目进行申请，中选后在项目开发者（社区导师）的指导下进行开发。根据项目的难易程度和完成情况，结项者将获取开源之夏活动奖金和结项证书。

开源之夏官网：[https://summer-ospp.ac.cn/](https://summer-ospp.ac.cn/)

## 我参与开源之夏的一些契机

首先介绍一下我的情况，我是一名研究生，今年的下半年就要找工作。一般来说应该在这个暑期找一份实习，来为后面的找工作做准备，但是很可惜，因为某些不可抗力，我无法实现这一计划。

不过这个时候我有同学给我分享了开源之夏（在这里我要非常感谢分享给我这个活动的同学🙇）。由于开源活动、开源实习基本是全程线上，适合因为某些原因无法实习的同学参与，刚刚好可以稍微替代一下暑期实习。

## 开源之夏的申请过程

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

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

在这个页面可以看到RT-Thread社区今年的项目列表。

[https://summer-ospp.ac.cn/org/orgdetail/8bce77cd-7c54-48b8-a3e6-f816338692cb](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://github.com/RT-Thread/pkgs-test)

## 项目介绍

官网的项目说明可以在这里查看

[https://summer-ospp.ac.cn/org/prodetail/238bc0128](https://summer-ospp.ac.cn/org/prodetail/238bc0128)

关于这个项目首先需要了解一下什么是RT-Thread的软件包，RT-Thread软件包是运行在RT-Thread系统上面的一套通用的代码库。相当于提供了很多模块，比如各种外设的驱动、工具等等，只要使用的是RT-Thread操作系统，就都可以导入并使用。RT-Thread软件包和RT-Thread操作系统一样是一个开源的平台，任何人都可以制作自己的软件包，也可以去帮助维护别人的软件包。

因为这种自由、开放的特性，软件包社区里面会遇到某些软件包无法使用、不能编译通过的问题。

- 版本迭代造成的编译问题（内核文件改动后，软件包没有去做版本控制）
- 架构冲突以及 bsp 依赖问题（某些软件包只在特定的架构或 bsp 中可用）

因此需要一个工具来暴露出社区软件包的相关编译问题。

## 使用场景

下面是软件包测试工具的使用场景。

1. 本地使用
    1. 对特定的软件包，在一些指定的bsp、rt-thread版本上进行测试。
    2. 指定某一个特定的版本或所有版本。
    3. 指定的软件包集合。
2. 作为Github Action使用，测试软件包是否支持一些rtt版本和bsp。
    1. 软件包开发者
        1. 软件包测试
            1. 更新软件包的代码之后，自动对软件包进行测试。
        2. rt-thread的master测试
            1. 定时对软件包进行测试，检查是否支持rt-thread的master版本。
    2. rt-thread社区维护人员
        1. 所有软件包测试
            1. 定时对全部软件包在master 分支或指定的一些版本上进行测试，并发布测试结果到github pages。
        2. 软件包索引更新测试
            1. 软件包索引发生改动时，对改动的部分软件包进行测试，在github pages上面更新这部分测试结果。
        3. rt-thread版本发布测试
            1. rt-thread版本发布后对全部的软件包进行测试。
        4. 精品软件包集合测试（TODO）
            1. 对一些制定的精品软件包集合进行测试，比如当rt-thread的master分支改动时，测试这些软件包。

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

[https://club.rt-thread.org/ask/article/9c05fc7fcc0223fe.html](https://club.rt-thread.org/ask/article/9c05fc7fcc0223fe.html)

## 项目工作

我在接手这个项目的时候，已经完成了本地测试的使用和软件包索引仓库使用的一些基本功能，我是在此基础上进行开发的。

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

- 将测试的一些参数（如内核版本，测试的bsp等）通过程序运行的参数传入。之前是通过修改配置文件来实现的，如果是作为ci工具使用不是很方便。
- 将软件包的测试结果生成json并发布到github pages，主要是提供一个获取软件包可用性的方式。完成了对新旧测试结果的合并，以及上传冲突的解决方案。

[https://rt-thread.github.io/packages/pkgs_res.json](https://rt-thread.github.io/packages/pkgs_res.json)

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

[https://rt-thread.github.io/packages/](https://rt-thread.github.io/packages/)

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

接下来主要的工作，就是去在RT-Thread仓库里面去集成这个工具，对rt-thread仓库的每次代码在一些精选的软件包上面进行测试。以及去完善一下自动测试后的反馈，每次测试结果都不是很方便查看，需要通过actions自动在pr里面回复相关的一些信息，让开发者能够更方便的了解到哪里出了问题，问什么没通过检查。