ROS 2开发人员指南 [待校准@449]
目录
本页定义了我们在开发ROS 2时采用的实践和政策。 [待校准@450]
质量实践 [待校准@456]
根据 REP 2004: Package Quality Categories 的指导方针，包装可以根据其遵守的开发版本实践归因于不同的质量水平。这些类别因其在版本控制、测试、文档编制等方面的政策而有所不同。 [待校准@457]
以下各节是我们遵循的具体开发版本规则，以确保核心包具有最高质量 ('Level 1')。我们建议所有ROS开发人员努力遵守以下政策，以确保整个ROS生态系统的质量。 [待校准@458]
版本控制 [待校准@459]
我们将使用 Semantic Versioning guidelines ( semver ) 进行版本控制。 [待校准@460]
我们还将遵守一些基于 “semver” 的特定ROS规则，其全部含义为: [待校准@461]
主要版本增量 (即中断更改) 不应在已发布的ROS发行版中进行。 [待校准@462]
对于编译代码，ABI被认为是公共接口的一部分。任何需要重新编译依赖代码的更改都被认为是主要的 (中断)。 [待校准@466]
ABI中断更改 * 可以 * 在 * 发行版之前 * 在次要版本中进行 (添加到滚动发行版中)。 [待校准@467]
我们对Dashing和Eloquent的核心包实施API稳定性，尽管它们的主要版本组件是
0，尽管 SemVer's specification 关于初始开发版本。 [待校准@468]随后，包应努力达到成熟状态，并增加到
1.0.0版本，以符合 “半个” 的规格。 [待校准@469]
注意事项 [待校准@470]
这些规则是 * 尽力而为 *。在不太可能的极端情况下，可能有必要在主要版本/发行版中破坏API。计划外的中断是增加主要版本还是次要版本将根据具体情况进行评估。 [待校准@471]
例如，考虑一种情况，包括释放的X-turtle (对应于主版 1.0.0 ) 和释放的Y-turtle (对应于主版 2.0.0 )。 [待校准@472]
如果在X-turtle中发现破坏API的修复是绝对必要的，那么撞到 2.0.0 显然不是一个选择，因为 2.0.0 已经存在。 [待校准@473]
在这种情况下，处理X-turtle版本的解决方案 (两者都不理想) 是: [待校准@474]
碰撞X-turtle的次要版本: 不理想，因为它违反了SemVer的原则，即打破变化必须碰撞主要版本。 [待校准@475]
碰撞X-turtle的主要版本超过Y-turtle (到
3.0.0): 不理想，因为旧发行版的版本会变得比新发行版的现有版本更高，这将使特定于版本的条件代码无效/中断。 [待校准@476]
开发人员必须决定使用哪种解决方案，或者更重要的是，他们愿意打破哪种原则。我们不能建议其中一个或另一个，但在这两种情况下，我们确实要求采取明确的措施来手动向用户传达中断及其解释 (不仅仅是版本增量)。 [待校准@477]
如果没有Y-turtle，即使修复程序将techni调用y只是一个补丁，X-turtle也必须碰到 2.0.0 。这种情况适用于SemVer，但违反了我们自己的规则，即在发布的发行版中不应引入主要增量。 [待校准@478]
这就是为什么我们考虑版本控制规则 * 尽力而为 *。尽管上述例子不太可能，但准确定义我们的版本控制系统是很重要的。 [待校准@479]
公共API声明 [待校准@480]
根据 semver ，每个包必须清楚地声明一个公共API。我们将使用包装质量声明的 "Public API Declaration" 部分来声明哪些符号是公共API的一部分。 [待校准@481]
对于大多数C和C + + 包，声明是它安装的任何标头。然而，定义一组被认为是私有的符号是可以接受的。避免标题中的私有符号有助于提高ABI的稳定性，但不是必需的。 [待校准@482]
对于Python等其他语言，必须明确定义公共API，以便清楚地了解版本控制指南可以依赖哪些符号。公共API也可以扩展到构建工件，如配置变量、CMake配置文件等，以及可执行文件、命令行选项和输出。公共API的任何元素都应在包的文档中明确说明。如果您使用的内容没有在包的文档中明确列出为公共API的一部分，那么您就不能依赖它而不在次要版本或补丁版本之间进行更改。 [待校准@483]
弃用策略 [待校准@484]
在可能的情况下，我们还将使用滴答作响的弃用和迁移策略来实现主要版本的增量。新的弃用将出现在新的发行版中，并伴随着编译器警告，表示该功能正在被弃用。在下一个版本中，该功能将被完全删除 (无警告)。 [待校准@485]
示例功能 foo 弃用替换功能 bar : [待校准@486]
版本 [待校准@336] |
API |
|---|---|
X-turtle [待校准@488] |
无效foo(); [待校准@489] |
Y龟 [待校准@490] |
[[已弃用 (“使用条 ()”)]] 无效foo(); <br> 无效条 (); [待校准@491] |
Z龟 [待校准@492] |
空隙条 (); [待校准@493] |
发布发行后，我们不得添加弃用项。然而，弃用不一定需要主要版本的提升。如果碰撞发生在发行版发布之前，则可以在次要版本碰撞中引入弃用 (类似于ABI破坏更改)。 [待校准@494]
例如，如果X-turtle开始以 2.0.0 的形式开发版本，则可以在X-turtle发布之前在 2.1.0 中添加弃用。 [待校准@495]
我们将尽量保持发行版之间的兼容性。然而，就像与SemVer相关的警告一样，在某些情况下，通常不可能完全遵守滴答滴答甚至弃用。 [待校准@496]
变更控制流程 [待校准@497]
所有更改必须经过拉取请求。 [待校准@498]
我们将在ROSCore仓库对拉取请求强制执行 Developer Certificate of Origin (DCO) 。 [待校准@499]
它要求所有提交消息都包含带有与提交作者匹配的电子邮件地址的
Signed-off-by行。 [待校准@500]您可以将
-s/--signoff传递给git commit调用，或者手动写入预期的消息 (例如Signed-off-by: Your Name Developer <your.name@example.com>)。 [待校准@501]对于仅解决空格删除、错字更正和其他 trivial changes 问题的拉取请求，不需要DCO。 [待校准@502]
始终为每个拉取请求的所有 tier 1 platforms 运行CI作业，并在拉取请求中包含指向作业的链接。(如果您无权访问Jenkins作业，则会有人为您触发作业。) [待校准@503]
未提交拉取请求的开发人员至少需要获得1的批准才能认为该请求已被批准。合并前需要批准。 [待校准@504]
包裹可以选择增加这个数量。 [待校准@505]
在合并相关变更之前，必须对文档 (API文档、特性文档、发行说明等) 提出任何必要的变更。 [待校准@506]
反向移植PRs指南 [待校准@507]
当更改旧版本的ROS时: [待校准@508]
在打开PR以将更改反向移植到旧版本之前，请确保功能或修复已被接受并合并到主分支中。 [待校准@509]
当反向移植到旧版本时，也可以考虑反向移植到任何其他 still supported versions, ，甚至非LTS版本。 [待校准@510]
如果您要全部反向移植单个PR，请将反向移植PR命名为 “[发行版] <原始PR的名称>”。如果从一个或多个PRs中反向移植变更的子集，标题应为 “[发行版] <变更描述>”。 [待校准@511]
从您的反向端口PR的描述链接到您要反向移植其更改的所有PR。在Foxy变更的Dashing反向端口中，您不需要链接到相同变更的Eloquent反向端口。 [待校准@512]
文档 [待校准@513]
所有包的自述文件中应包含这些文档元素，或从自述文件中链接到这些文档元素: [待校准@514]
描述和目的 [待校准@515]
公共API的定义和描述 [待校准@516]
示例 [待校准@322]
如何构建和安装 (应参考外部工具/工作流) [待校准@517]
如何构建和运行测试 [待校准@518]
如何构建文档 [待校准@519]
如何开发 (有助于描述
python setup.py develop之类的东西) [待校准@520]许可和版权声明 [待校准@521]
每个源文件必须具有许可和版权声明，并通过自动链接进行检查。 [待校准@522]
每个包必须有一个许可证文件，通常调用Apache 2.0许可证，除非包有现有的许可许可证 (例如，rviz使用三条款BSD)。 [待校准@523]
每个包都应该尽可能地描述自己和它的目的，假设读者在没有ROS或其他相关项目的情况下偶然发现了它。 [待校准@524]
每个包都应定义和描述其公共API，以便用户对语义版本控制策略所涵盖的内容有合理的期望。即使在C和C ++ 中，公共API也可以通过API和ABI检查来强制执行，这是一个描述代码布局和代码各部分功能的好机会。 [待校准@525]
获取任何包应该很容易，并且从该包的文档中了解如何构建、运行、构建和运行测试以及构建文档。显然，对于常见的工作流，我们应该避免重复自己，例如在工作区中构建包，但是基本的工作流应该被描述或引用。 [待校准@526]
最后，它应该包括开发人员的任何文档。这可能包括使用 python setup.py develop 之类的东西测试代码的工作流，或者它可能意味着描述如何使用包提供的扩展点。 [待校准@527]
示例: [待校准@528]
能力: https://docs.ros.org/hydro/api/capabilities/html/ [待校准@529]
本文给出了描述公共API的文档示例 [待校准@530]
[需手动修复的语法]catkin _ 工具: https://[需手动修复的语法]catkin -tools.readthedocs.org/en/latest/ 开发版本/extending_the _ [需手动修复的语法]catkin _ command.html [待校准@531]
这是描述包的扩展点的示例 [待校准@532]
(API docs are not yet being automatically generated)
测试 [待校准@534]
所有包都应具有一定程度的系统、集成和/或单元测试。 [待校准@535]
单元测试应该始终在正在测试的包中，并且应该使用像 Mock 这样的工具在构建的场景中尝试和测试代码库的狭窄部分。单元测试不应引入非测试工具的测试依赖关系，例如gtest、nosetest、pytest、mock等。 [待校准@536]
集成测试可以测试部分代码之间或部分代码与系统之间的交互动作。他们经常以我们期望用户使用的方式测试软件界面。与单元测试一样，集成测试应位于正在测试的包中，除非绝对必要，否则不应引入非工具测试依赖项，即所有非工具依赖关系只能在极端审查下被允许，因此如果可能的话，应该避免它们。 [待校准@537]
系统测试旨在测试包之间的端到端情况，并且应该在自己的包中，以避免膨胀或耦合包，并避免循环依赖。 [待校准@538]
通常，应避免最小化外部或交叉包测试依赖关系，以防止循环依赖关系和紧密耦合的测试包。 [待校准@539]
所有的包都应该有一些单元测试和可能的集成测试，但是它们应该有多少是基于包的质量类别。以下小节适用于'Level 1'包: [待校准@540]
代码覆盖范围 [待校准@541]
我们将提供线路覆盖，并实现95% 以上的线路覆盖。如果一个较低的百分比目标是合理的，它必须被显著地记录下来。我们可能会提供分支覆盖范围，或者从覆盖范围中排除代码 (测试代码、调试代码等)。在合并更改之前，我们要求覆盖率增加或保持不变，但是在适当的理由下进行降低代码覆盖率的更改可能是可以接受的 (例如g.删除先前涵盖的代码可能会导致百分比下降)。 [待校准@542]
性能 [待校准@543]
我们强烈推荐性能测试，但要认识到它们对于某些包没有意义。如果有性能测试，我们将选择检查每个更改或在每次发布之前或两者都检查。我们还需要合并变更或发布降低性能的理由。 [待校准@544]
林特和静态分析 [待校准@545]
我们将使用 ROS code style and enforce it with linters from ament_lint_common 。必须使用属于 ament_lint_common 的所有漆器/静态分析。 [待校准@546]
[需手动修复的语法] ament_lint_auto 文件提供了运行 ament_lint_common 的信息。 [待校准@547]
一般实践 [待校准@548]
有些实践对于所有ROS 2开发版本都是常见的。 [待校准@549]
如 REP 2004 所述，这些做法不会影响包装质量水平，但仍强烈建议用于开发版本过程。 [待校准@550]
问题 [待校准@551]
提交问题时，请确保: [待校准@552]
包括足够的信息让其他人理解这个问题。在ROS 2中，需要以下几点来缩小问题的原因。在每个类别中尽可能多的备选方案进行测试将会特别有帮助。 [待校准@553]
操作系统和版本。推理: ROS 2支持多个平台，并且某些错误特定于特定版本的操作系统/编译器。 [待校准@554]
安装方法。推理: 有些问题只有在ROS 2是从 "fat archives" 或Debians安装的情况下才会显现。这可以帮助我们确定问题是否与包装过程有关。 [待校准@555]
ROS 2的特定版本。推理: 某些错误可能会出现在特定的ROS 2版本中，并在以后修复。了解您的安装是否包含这些修复程序非常重要。 [待校准@556]
DDS正在使用的DDS/RMW实施 ** (有关如何确定哪一个，请参阅 this page )。推理: 通信问题可能特定于正在使用的底层ROS中间件。 [待校准@557]
正在使用的ROS 2客户端库。推理: 这有助于我们缩小堆栈中问题所在的层。 [待校准@558]
包括重现问题的步骤列表。 [待校准@559]
如果发生错误，请考虑提供 short, self contained, correct (compilable), example 。如果其他人可以轻松地重现问题，则问题更有可能得到解决。 [待校准@560]
提及已尝试的故障诊断工具步骤，包括: [待校准@561]
升级到最新版本的代码，其中可能包括尚未发布的错误修复。查看 this section 并按照说明获取 "master" 分支。 [待校准@562]
拉取请求 [待校准@564]
拉取请求应仅关注一个更改。单独的更改应进入单独的请求请求。见 GitHub's guide to writing the perfect pull request 。 [待校准@565]
补丁的大小应最小，并避免任何不必要的更改。 [待校准@566]
拉取请求必须包含最少数量的有意义的提交。 [待校准@567]
您可以在审核拉取请求时创建新提交。 [待校准@568]
在合并拉取请求之前，应将所有更改压缩为少量语义提交，以保持历史记录清晰。 [待校准@569]
但避免在审核拉取请求时压缩提交。你的评论者可能不会注意到你做了改变，从而引入了潜在的混乱。另外，无论如何，你都要在合并前挤压; 早点做没有好处。 [待校准@570]
欢迎任何开发者审查和批准拉取请求 (见 General Principles )。 [待校准@571]
当您开始查看拉取请求时，请对拉取请求进行注释，以便其他开发人员知道您正在查看它。 [待校准@572]
拉取请求审阅不是只读的，审阅者会发表评论，然后等待作者提出评论。作为一名审稿人，可以在适当的位置进行一些小的改进 (打字错误、风格问题等)。作为拉取请求的开启者，如果你在叉子上工作，检查 allow edits from upstream contributors 的方框将有助于完成上述工作。作为审阅者，也可以随意进行更多实质性的改进，但可以考虑将它们放在单独的分支中 (或者在评论中提及新分支，或从新分支打开另一个拉取请求到原始分支)。 [待校准@573]
任何开发人员 (作者、审阅者或其他人) 都可以合并任何已批准的拉取请求。 [待校准@574]
库版本控制 [待校准@575]
我们将一起对包中的所有库进行版本化。这意味着库从包继承其版本。这防止了库和包版本的分歧，并与发布共享仓库的包的政策共享推理。如果您需要库具有不同的版本，请考虑将它们拆分为不同的包。 [待校准@576]
开发流程 [待校准@577]
默认分支 (大多数情况下是主分支) 必须始终构建、通过所有测试并在没有警告的情况下进行编译。如果在任何时候都有回归，那么至少恢复以前的状态是重中之重。 [待校准@578]
始终在启用测试的情况下构建。 [待校准@579]
始终在更改之后和在拉取请求中提出之前运行测试lo调用y。除了使用自动化测试之外，还可以手动运行修改后的代码路径，以确保补丁按预期工作。 [待校准@580]
始终为每个拉取请求为所有平台运行CI作业，并在拉取请求中包含指向作业的链接。 [待校准@581]
有关推荐的软件开发版本工作流程的更多详细信息，请参见 Software Development Lifecycle 部分。 [待校准@582]
对RMW API的更改 [待校准@583]
在更新 RMW API 时，也需要更新一级中间件库的RMW实现。例如，引入到RMW API的新功能 rmw_foo() 必须在以下包中实现 (从ROSFoxy开始): [待校准@584]
如果可行，还应考虑对非第1层中间件库进行更新 (例如，取决于更改的大小)。有关中间件库及其层的列表，请参见 REP-2000 。 [待校准@588]
跟踪任务 [待校准@589]
为了帮助组织ROS 2的工作，核心ROS 2开发版本团队使用看板式 GitHub project boards 。 [待校准@590]
然而，并不是所有的问题和请求都在项目板上被跟踪。董事会通常代表即将发布的版本或特定项目。通过浏览 ROS 2 repositories' 个人发行页面，可以按回购原则浏览门票。 [待校准@591]
在任何给定的ROS 2项目委员会中，列的名称和目的各不相同，但通常调用y遵循相同的一般结构: [待校准@592]
待办事项: 与项目相关的问题，准备分配 [待校准@593]
进行中: 当前正在进行工作的活动拉取请求 [待校准@594]
审核中: 在工作完成并准备审核的地方以及当前正在进行审核的请求 [待校准@595]
完成: 拉取请求和相关问题被合并/关闭 (出于信息目的) [待校准@596]
要请求进行更改的权限，只需对您感兴趣的门票进行评论。根据复杂性，描述您计划如何解决它可能会很有用。我们将更新状态 (如果您没有权限)，您可以开始处理拉取请求。如果您定期投稿，我们可能只会允许您自己管理标签等。 [待校准@597]
文件系统布局 [待校准@606]
包和仓库的文件系统布局应遵循相同的约定，以便为浏览我们源文件的用户提供一致的体验。 [待校准@607]
包装布局 [待校准@608]
[需手动修复的语法]``src``:包含所有C和C code代码 [待校准@609]
还包含未安装的C/C headers标头 [待校准@610]
[需手动修复的语法]``include``:包含所有已安装的C和C ++ 标头 [待校准@611]
[需手动修复的语法]``<package name>``:所有C C++ 安装标题应该文件夹命名空间包名称 [待校准@612]
[需手动修复的语法]``<package_name>``:包含所有Python代码 [待校准@613]
[需手动修复的语法]``test``:包含所有自动化测试和测试数据 [待校准@614]
[需手动修复的语法]``config``:包含配置文件，例如YAML参数文件和RViz配置文件 [待校准@615]
[需手动修复的语法]``doc``:包含所有文件 [待校准@616]
[需手动修复的语法]``launch``:包含所有launch文件 [待校准@617]
仅使用CMake的``CMakeLists.txt``:ROS包 [待校准@619]
仅使用Python代码的``setup.py``:ROS包 [待校准@620]
[需手动修复的语法]``README``:可以作为项目的登录页面在GitHub上呈现 [待校准@621]
[需手动修复的语法]``CONTRIBUTING``:描述了贡献指南 [待校准@625]
这可能包括许可证含义，例如使用Apache 2许可证时。 [待校准@626]
[需手动修复的语法]``LICENSE``:: 此包的一个或多个许可证的副本 [待校准@627]
开发人员工作流 [待校准@631]
我们使用 GitHub project boards 追踪与即将到来的发行版本和大型项目相关的公开票据和有效的PRs。 [待校准@632]
通常的工作流程是: [待校准@633]
讨论设计 (GitHub票适当仓库，设计PR https://github.com/ros2/设计如果需要) [待校准@634]
在分叉上的功能分支上编写实现 [待校准@635]
请查看 developer guide 指南和最佳实践 [待校准@636]
编写测试 [待校准@637]
启用并运行linters [待校准@638]
运行测试lo调用y使用
colcon test(见 colcon tutorial) [待校准@639]一旦一切都在没有警告的情况下构建了lo调用y，并且所有测试都通过了，请在您的功能分支上运行CI: [待校准@640]
转到ci.ros2.org [待校准@641]
登录 (右上角) [待校准@642]
点击
ci_launcher作业 [待校准@643]点击 "Build with Parameters" (左栏) [待校准@644]
在第一个框中， "CI_BRANCH_TO_TEST" 输入您的特征分支名称 [待校准@645]
按下
build按钮 [待校准@646]
(如果您不是ROS 2提交者，则无法访问CI场。在这种情况下，请ping您的PR的审阅者以为您运行CI) [待校准@647]
如果您的用例需要运行代码覆盖率: [待校准@648]
如果CI作业在没有警告、错误和测试失败的情况下构建，请将您的作业链接发布在您的PR或汇总您所有PRs的高级票证上 (请参阅示例 here ) [待校准@652]
请注意，这些徽章的降价是在
ci_launcher作业的控制台输出中。 [待校准@653]
当公共关系被批准时: [待校准@654]
合并后删除分支 [待校准@658]
建筑开发实践 [待校准@659]
本节介绍在对ROS 2进行大型架构更改时应采用的理想生命周期。 [待校准@660]
软件开发生命周期 [待校准@661]
本节介绍如何逐步规划、设计和实施新功能: [待校准@662]
任务创建 [待校准@663]
创建设计文档 [待校准@664]
设计审查 [待校准@665]
实现 [Alyssa@666]
代码审查 [待校准@667]
任务创建 [待校准@668]
需要更改ROS 2关键部分的任务应在发布周期的早期阶段进行设计审查。如果设计审查在后期进行，这些变化将成为未来版本的一部分。 [待校准@669]
一个问题应该在适当的 ros2 repository 中产生，清楚地描述正在进行的任务。 [待校准@670]
编写设计文件 [待校准@673]
设计文件不得包含机密信息。更改是否需要设计文档取决于任务的大小。 [待校准@674]
您正在做一个小的改变或修复一个错误: [待校准@675]
不需要设计文件，但应在适当的仓库中打开问题，以跟踪工作并避免重复工作。 [待校准@676]
您正在实施一项新功能，或者希望为OSRF拥有的基础设施 (如Jenkins CI) 做出贡献: [待校准@677]
设计文档是必需的，并且应该有助于 ros2/design ，以便在https:// Design.ros2.org/上访问。 [待校准@678]
你应该分叉仓库，并提交一份详细设计的拉取请求。 [待校准@679]
提及相关的ros2问题 (例如，
Design doc for task ros2/ros2#<issue id>) in the pull request or the commit message. Detailed instructions are on the ROS 2 Contribute 页面。设计评论将直接根据拉取请求进行。 [待校准@680]
如果计划使用特定版本的ROS发布任务，则此信息应包含在拉取请求中。 [待校准@681]
设计文件审查 [待校准@682]
一旦设计准备好审查，就应该打开拉取请求，并分配适当的审查人员。建议包括项目所有者 -- 所有受影响包的维护者 (如 package.xml 维护者字段所定义，见 REP-140 ) -- 作为审查者。 [待校准@683]
如果设计文档很复杂或审阅者的时间表冲突，则可以设置可选的设计审阅会议。在这种情况下， [待校准@684]
会议前 [待校准@685]
会议期间 [待校准@691]
任务负责人推动会议，提出他们的想法并管理讨论以确保按时达成协议 [待校准@692]
会后 [待校准@693]
一旦达成共识: [待校准@702]
如果适用，确保 ros2/design 拉取请求已被合并 [待校准@703]
更新并关闭与此设计任务相关的GitHub问题 [待校准@704]
实现 [Alyssa@666]
在开始之前，通过 Pull requests 部分的最佳实践。 [待校准@705]
对于要修改的每个回购: [待校准@706]
修改代码，如果完成，请转到下一步，或者定期备份您的工作。 [待校准@707]
[需手动修复的语法] Self-review 乙你的变化使用
git add -i。 [待校准@708]使用
git commit -s创建新的签名提交。 [待校准@709]
代码审查 [待校准@715]
一旦更改准备好进行代码审查: [待校准@716]
建立农场介绍 [待校准@725]
建造农场位于 ci.ros2.org 。 [待校准@726]
每天晚上，我们都会运行夜间作业，这些作业在各种平台上构建和运行各种场景中的所有测试。此外，我们在合并之前针对这些平台测试所有拉取请求。 [待校准@727]
这是当前的一组目标平台和架构，尽管它会随着时间的推移而发展: [待校准@728]
Ubuntu 20.04焦点 [待校准@729]
macOS 10.14 Mojave [待校准@732]
amd64 [待校准@730]
Windows 10 [待校准@733]
amd64 [待校准@730]
buildfarm上有几类作业: [待校准@734]
手动作业 (由开发人员手动触发): [待校准@735]
每晚 (每晚跑步): [待校准@742]
包装 (每晚运行; 结果被捆绑到archive中): [待校准@761]
另外两个构建农场通过提供源文件和二进制包的构建、持续集成、测试和分析来支持ROS/ROS 2生态系统。 [待校准@765]
有关详细信息、常见问题和故障诊断工具，请参见 build farms 。 [待校准@766]
关于覆盖运行的注意事项 [待校准@767]
ROS 2包的组织方式是，给定包的测试代码不仅包含在包中，还可以存在于不同的包中。换句话说: 包可以在测试阶段执行属于其他包的代码。 [待校准@768]
为了实现ROS 2核心包中所有可用代码达到的覆盖率，建议使用一组固定的建议仓库运行构建。该集合在Jenkins覆盖作业的默认参数中定义。 [待校准@769]
如何从buildfarm报告中读取覆盖率 [待校准@770]
要查看给定包的覆盖报告: [待校准@771]
当
ci_linux_coverage建造完成后，点击Coverage Report[待校准@772]向下滚动至
Coverage Breakdown by Package表 [待校准@773]在表中，查看调用ed "Name" 的第一列 [待校准@774]
buildfarm中的覆盖率报告包括ROS工作区中使用的所有包。覆盖率报告包括对应于同一包的不同路径: [待校准@775]
如何从buildfarm报告中计算覆盖率 [待校准@779]
使用自动脚本获取合并的单位覆盖率: [待校准@780]
备选方案: 从覆盖报告中获取组合单位覆盖率 (需要手动计算): [待校准@785]
如何使用lcov (Ubuntu) 测量覆盖率lo调用y [待校准@791]
要测量您自己机器的覆盖范围，请安装 lcov 。 [待校准@792]
sudo apt install -y lcov
本节的其余部分假设您正在colcon工作区工作。使用覆盖率标志在debug中编译。随意使用colcon标志特定包。 [待校准@793]
colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} --coverage" -DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} --coverage"
[需手动修复的语法]``lcov`` requires是初始基线，您可以使用以下命令生成该基线。根据需要更新输出文件位置。 [待校准@794]
lcov --no-external --capture --initial --directory . --output-file ~/ros2_base.info
对与您的覆盖率测量有关的包进行测试。例如，如果用 test_rclcpp 测量 rclcpp [待校准@795]
colcon test --packages-select rclcpp test_rclcpp
这次用类似的命令捕获lcov结果，删除 --initial 旗。 [待校准@796]
lcov --no-external --capture --directory . --output-file ~/ros2.info
合并跟踪。信息文件: [待校准@797]
lcov --add-tracefile ~/ros2_base.info --add-tracefile ~/ros2.info --output-file ~/ros2_coverage.info
生成html以便于可视化和注释覆盖行。 [待校准@798]
mkdir -p coverage
genhtml ~/ros2_coverage.info --output-directory coverage