Supper Thomas
Supper Thomas
最近有点感冒。
6.29 俯卧撑 20个+10
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax
gitlab 参考： https://docs.gitlab.cn/14.9/jh/user/project/code_owners.html#%E8%AE%BE%E7%BD%AE%E4%BB%A3%E7%A0%81%E6%89%80%E6%9C%89%E8%80%85
相对路径 如果路径不以 / 开头，则路径将被视为以[星号](https://docs.gitlab.cn/jh/user/project/codeowners/reference.html#globstar-paths)开头。README.md 的处理方式与 /**/README.md 相同：
CODEOWNER语法参考。 https://docs.gitlab.cn/jh/user/project/codeowners/reference.html
branch看起来指定不了，直接改branch下面的CODEOWNER即可。
参考： https://github.com/zephyrproject-rtos/zephyr/tree/main/tests/drivers
>题目12：提供驱动验证自动测试用例和代码覆盖率 进阶 提议人：supperthomas 导师: 陈迎春 为rtthread的bsp构建一套基础的测试用例，可以用测试框架 目标： 目前在master分支中的大部分的bsp，有很多只是实现了部分功能，很多项目在用的时候会发现缺这缺那，我们需要做一个或者多个软件包，来设计不同的API的应用场景和使用规则，模拟上层应用在调驱动的时候一些行为。要求该软件包可以测试出，例如GPIO驱动如果没有做输入功能，通过运行软件包能够检查到这个内容。测试用例要尽可能多的测试所有接口的功能和应用场景。 基于以下几种测试场景进行构思测试用例： 1.单板内模块和模块之间通过连线对测用例。 2.双板之间通过不同模块之间对测用例。 3.单板与拓展底板之间的对测用例。（如果能够整理一套通用的硬件测试底板，基于同一套底板测试，基于arduino接口对接测试更好） 整个的思路需要描述一下，是否具备可行性 产出标准： 1.能够检测出不同bsp中缺少哪些驱动文件。 2.能够检测出不同bsp中已经做出的驱动哪些接口未实现，哪些功能没有完善。驱动有I2C, SPI, PIN, PWM, WATCHDOG. RTC, UART, ADC,DAC,UART. 3.以STM32 H750为模板，来验证其他bsp的功能是否ok，比如Nordic， LPC 4.把BSP中经过测试的驱动中的一些缺少的部分可以尽量完善PR（可以完善一些熟悉的） 5.通过使用该软件包，能够实现在实现bsp的驱动功能的时候能够简单高效，并且提PR。 6.最后采用gcovr等软件能够直观的显示代码覆盖率（进阶任务） 7.定期的输出学习文档或者贡献代码(至少两周要提供一次)...