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

2023/08/24 19:59
阅读数 143
AI总结

前言


开源之夏是什么 

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

开源之夏是开源软件供应链点亮计划下的⼀个暑期活动,由中国科学院软件研究所与 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. 软件包开发者

  1. 软件包测试:更新软件包的代码之后,⾃动对软件包进⾏测试。

  2. rt-thread的master测试:定时对软件包进⾏测试,检查是否⽀持rt-thread的master版本。

b. rt-thread社区维护⼈员

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

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

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

  4. 精品软件包集合测试(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⾥⾯回复相关的⼀些信息,让开发者能够更⽅便的了解到哪⾥出了问题,为什么没通过检查。


———————End——————




👇 点击阅读原文进入官网

本文分享自微信公众号 - RTThread物联网操作系统(RTThread)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
AI总结
返回顶部
顶部