添加新的 CI 作业¶
新的 CI 作业需要遵循特定的流程进行添加，以确保它们不会不必要地阻塞补丁，并且不会被开发者忽略。
问题描述¶
我们需要制定一个添加 CI 作业的流程，避免因新作业导致大量虚假失败。错误的 CI 结果会强制进行额外的重新检查，并降低开发者/审查者的信心。
此外，维护 CI 作业是一项不简单的任务，我们添加的每个作业都会增加团队的负担。希望通过制定一个需要新作业提出者参与的流程，能够明确提出作业的人/团队有责任帮助维护它。CI 是每个人的问题。
策略¶
添加新作业时，应按以下顺序完成以下步骤
为单个 Gerrit 变更创建一个实验性作业或劫持一个现有作业。有关如何添加新作业的详细信息，请参阅参考部分。此作业应通过测试后才能进行下一步。
验证新作业是否提供了合理的日志记录级别。不要过多，也不要过少。重要的日志，例如 OpenStack 服务日志和基本系统日志，对于确定作业失败的原因至关重要。但是，OpenStack Infra 必须存储来自大量作业的日志，因此保持我们的日志工件大小在控制范围内也很重要。如有疑问，请尝试捕获与现有作业相同数量的日志。
将作业提升为非投票状态。虽然作业在此之前应该已经通过测试，但它可能还没有运行很多次，因此整体稳定性仍然未知。
在这种情况下，“稳定”的定义是不比 ovb-ha 作业产生明显更多的虚假失败。由于 HA 部署的额外复杂性，该作业比其他作业更容易因与正在测试的补丁无关的原因而失败。我们不想添加任何不稳定的作业。请注意，由于新作业捕获的合法问题导致的失败不应计入其稳定性。
重要
在将 OVB 作业添加到检查队列中，即使是非投票状态，请与 CI 管理员联系，以确保有足够的 OVB 容量来运行大量新作业。截至撰写本文时，OVB 云容量比常规 OpenStack Infra 容量受到更多限制。
作业应保持这种状态，直到经过一段时间的验证证明其稳定。一个好的经验法则是，经过一周的稳定性后，该作业可以并且应该进入下一步。
重要
作业不应无限期地保持非投票状态。这会导致审查者忽略结果，因此这些作业会浪费资源。一旦认为作业稳定，应尽快使其成为投票作业。
为了帮助确认作业的稳定性，应将其添加到 CI 状态 页面。这实际上可以在作业移动到检查队列后的任何时间完成，但必须在作业成为投票作业之前完成。
此外，请联系 Sagi Shnaidman (sshnaidm on IRC)，以将作业添加到 扩展 CI 状态 页面。
向 openstack-dev 发送一封电子邮件，并标记为 [tripleo]，解释新作业的目的，并通知人们它即将成为投票作业。
使作业成为投票作业。此时，应该对作业有足够的信心，审查者可以信任结果，并且不应合并任何未通过该作业的内容。
此外，请注意，投票多节点作业也是门控。如果作业失败，则补丁无法合并。这意味着一个损坏的作业会阻止所有 TripleO 更改的合并。
继续关注 CI 状态 页面，以确保作业继续顺利运行。如果它开始出现异常多的失败，请进行调查。
替代方案与历史¶
从历史上看，许多作业在完全损坏的情况下被添加到检查队列中。这是不好的，会降低开发者和审查者对 CI 结果的信心。如果损坏的作业是门控作业，它也可能阻止 TripleO 更改的合并。
我们还有一个不良习惯，即让作业保持非投票状态，这使得它们几乎毫无价值，因为审查者不会尊重结果。根据此策略，我们应该清理所有非投票作业，要么将其移回实验状态，要么稳定它们并使其成为投票作业。
实现¶
里程碑¶
此策略将立即生效。
工作项¶
此策略主要针对新作业，但我们确实有一些非投票作业需要使其符合该策略。
参考资料¶
修订历史¶
发布名称 |
描述 |
|---|---|
Pike |
引入 |
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
