我们使用 Travis CI 在 git 上维护我们的项目。这里的问题是在 Travis 上，我们有 2 个进程运行随机选择的规格，每个规格都有不同的种子编号，现在当出现故障时，我尝试运行：
在调试 travis 构建时，无论是在本地还是在 ssh 上，在以上 5 个场景中，我发现没有失败，并且 bisect 总是失败。
同样在一个完全不同的场景中，如果我使用默认的 8 个进程在本地运行 parallel:spec，我确实会失败，但是如果我使用“rspec”cmd 单独运行每个，则不会失败。
我还尝试在本地运行 parallel:spec，同时在应用程序根目录中的 .parallel-spec 文件中使用 --bisect 选项。我得到的最小复制命令仍然没有失败。
我在这里错过了什么？这个问题是否与运行多个进程以及必须使用 rspec 运行最少的复制行有关？因为目前在我看来，如果规范在超过 1 个进程上运行，我将永远无法重现失败的规范。另一方面，如果我在本地运行 rspec --bisect 8 小时后，我发现它甚至没有启动 1 个进程，而且我在 macbook pro 上（但是是的，我们有大约 4k 规格）
附注我们在 rails 4.2.7.1、ruby 2.3.3 和 rspec 3.4.4
上谢谢
更新：运行 parallel spec verbose 以获得 specs 顺序，然后运行 process 命令，其中 spec 以种子号失败，然后另一次以种子号和 --bisect 失败。仍然没有失败。
在你尝试的那5件事中我看不到
Try to run all the specs from the process with the seed您的规范可能会相互干扰，如果规范 A 在规范 B 之前运行，则会导致 B 失败... 或者即使 A 在 B 之前运行，它也可能导致 C 失败。
因此，如果您使用种子运行一个进程的所有规范 - 也许您会重现失败 - 只有这样您才能使用
--bisect如果你不能那样重现它 - 我可以看到另一个选项：你的并行规范正在使用共享资源（数据库，文件？）并且失败是由竞争条件引起的。这些很难找到 - 特别是在规格中。确保每个进程实际使用一个单独的数据库（简单的错误，比如忘记更改 database.yml 可能会导致这种情况）。
如果这没有帮助 - 检查您的代码是否有其他可能的共享资源。 您没有提到通常有多少规格会失败。如果它是一个小数字 - 你可以专注于那些。
您可能正在处理两个测试之间的竞争条件，这两个测试正在访问 CI 中的同一个共享全局数据存储，可能是 memcached、Redis 或其他一些共享数据。
这是我之前在 hunting down flakiness 上回答过的一个问题。