注意
本文档适用于 Ceph 的开发版本。
Testing - Windows
自 Pacific 版本以来，Ceph 客户端工具和库可以在 Windows 上原生使用。这使得 Windows 节点无需 iSCSI 网关或 SMB 共享等额外层即可使用 Ceph。
为了确保这些组件在 Windows 上继续正常运行，我们移植了大量的单元测试和集成测试。
Windows CI Job
Windows CI 作业为每个 GitHub 拉取请求执行以下步骤：
启动一个 Linux VM，用于构建服务端（Linux）Ceph 二进制文件并交叉编译 Windows（客户端）二进制文件。
重新创建 Linux VM 并启动一个 Ceph vstart 集群。
启动一个 Windows VM 并在那里运行 Ceph 测试。
一个小的 PowerShell 框架并行化测试、聚合结果并隔离或跳过一些已知不稳定的测试。
控制台输出可能包含编译错误以及失败测试的名称。要获取失败测试的控制台输出以及 Ceph 和操作系统日志，请查看 Jenkins“状态”页面上的构建 artifacts。
Windows CI artifacts 可以下载为 zip 存档或在浏览器中查看。点击“artifacts”按钮查看 artifacts 文件夹的内容。
Artifact contents
client/- Ceph 客户端日志 (Windows)eventlog/- Windows 系统日志logs/- Ceph 日志-windows.conf- Ceph 配置文件
cluster/- Ceph 服务端日志 (Linux)ceph_logs/journal
test_results/out/- 按测试可执行文件分组的原始和 xml 测试输出test_results.html- 聚合测试报告 (html)test_results.txt- 聚合测试报告 (纯文本)
我们使用 subunit 格式和相关工具来聚合测试结果，这在并行运行大量测试时特别方便。
聚合测试报告提供了失败测试的绝佳概览。转到文件末尾查看实际错误。
{0} unittest_mempool.mempool.bufferlist_reassign [0.000000s] ... ok
{0} unittest_mempool.mempool.bufferlist_c_str [0.006000s] ... ok
{0} unittest_mempool.mempool.btree_map_test [0.000000s] ... ok
{0} ceph_test_dokan.DokanTests.test_mount [9.203000s] ... FAILED
Captured details:
~~~~~~~~~~~~~~~~~
b'/home/ubuntu/ceph/src/test/dokan/dokan.cc:136'
b'Expected equality of these values:'
b' wait_for_mount(mountpoint)'
b' Which is: -138'
b' 0'
b''
b'/home/ubuntu/ceph/src/test/dokan/dokan.cc:208'
b'Expected equality of these values:'
b' ret'
b' Which is: "ceph-dokan: exit status: -22"'
b' ""'
b'Failed unmapping: Y:\\'
{0} ceph_test_dokan.DokanTests.test_mount_read_only [9.140000s] ... FAILED
html 报告方便地按测试套件（测试二进制文件）对测试结果进行分组。出于安全原因，默认不渲染，但可以下载并在本地查看。
超时和缺失的测试结果通常表明进程崩溃。请注意，在执行测试前后，控制台上会打印 ceph 状态，这有助于识别崩溃的服务。
您可能还需要检查服务日志（包括客户端和服务器端）。另外，请注意，Windows “应用程序”事件日志将在 Windows 进程崩溃时包含条目。
Frequently asked questions
为什么 Windows CI 作业是我的 PR 上唯一失败的？
Ceph 集成测试通常通过 Teuthology 在 Ceph Lab 基础设施上执行。这些测试由 Ceph QA 团队按需触发，不会为每个提交的拉取请求自动运行。
由于 Windows CI 作业只关注客户端 Ceph 组件，因此它可以为 GitHub 上的每个拉取请求及时运行各种集成测试。换句话说，它运行各种 librados、librbd 和 libcephfs 测试，而其他检查（如“make check”）不会运行。
因此，Windows CI 经常会捕获其他检查遗漏的回归，否则这些回归只会通过 Teuthology 才会发现。通常，这些回归不是特定于平台的，也会影响 Linux。
如果 Windows CI 失败，我们强烈建议按照上述说明检查测试结果。
请注意，Windows 构建脚本可能使用不同的编译标志和传递给 CMake 的 -D 选项。例如，它默认为 Release 模式而不是 Debug 模式。同时，它使用不同的工具链 (mingw-llvm) 和一套独立的依赖项，如果需要，请确保更新版本。
为什么 Windows CI 作业是强制性的？
最初，测试作业是可选的，因此经常引入回归。
一段时间后，Windows 支持变得足够成熟，可以使这个 CI 作业成为强制性的。这大大减少了解决回归所需的工作量，并向 Ceph 用户保证了持续的 Windows 支持。
如前所述，另一个巨大的优势是它运行集成测试，可以快速捕获通常也影响 Linux 构建的回归。这使开发人员无需等待完整的 Teuthology 结果。