实施批准的提案

本文介绍了提案实施和发布阶段中模式提案工作流程的操作。

一旦模式提案被批准，其变更需要实施。对于实施变更的人员，将批准的模式变更拖到他们的IDE中是一个很好的开始。已批准的模式变更是解析器和任何其他需要实施的支撑代码的指南。

一旦实施更改，您可以使用模式检查来确保您的组织仅发布通过提案批准的更改。

使用Rover提取拟议的模式

“rover subgraph fetch 命令可以从变体和提案中获取子图模式。要从提案中获取子图模式，请使用提案的ID而不是变体名称：

rover subgraph fetch my-graph@p-101 --name subgraph

提案的ID总是以p-开头，后跟一个数字。您可以在GraphOS Studio中的提案URL中找到提案ID。例如，具有以下URL的提案的ID为p-101。

https://studio.apollographql.com/graph/Example-supergraph/proposal/p-101/home

使用检查验证更改

GraphOS提供模式检查以帮助您识别破坏性更改。在发布更改之前，您可以在本地更改上运行检查。

自以来自动运行在每个修订中的架构检查，如果你的上一个修订的检查通过，任何你在本地实施的变化都应该可以通过。不管怎样，最好在发布更改之前运行检查，以确保错误不会悄悄进来。

确保更改与已批准的提案一致

你可以配置在GraphOS中运行的架构检查，以包括一个提案任务。提案检查将验证正在运行的检查所改动的内容是否具有匹配和已批准的架构提案。

将提案任务的严重性设置为错误确保只有通过提案过程批准的更改才能发布。通过将严重性设置为警告，您可以发布尚未批准的更改并收到关于它们的警告。

当提案任务运行时，您可以通过点击检查页面上的检查页面的提案来查看哪些更改与提案相匹配：

• 显示有匹配批准提案的更改的复选标记图标。
• 没有匹配批准提案的更改将显示根据配置的严重性的警告或错误图标。

点击图标可以在右侧面板中显示匹配的提案列表。点击忽略可以允许提案任务在不匹配所有已批准提案的情况下成功。

将提案与更改匹配

即将到来的更改和批准的提案不必一对一匹配。例如，假设您有一个在多个子图中更改的已批准提案。您可以为每个子图的更改分别进行检查。即使更改不包括所有已批准提案的更改，各子图的检查也会通过。

同样，单个提案可以包含一个大子图的更改，您可以将这些更改分成多个检查。这些更改可以跨越多个检查并通过每个检查。

将更改发布到GraphOS

一旦实施了批准的架构更改，包括支持的代码，您需要将子图架构重新发布到GraphOS。发布架构提案更改遵循与其他任何更改相同的步骤。

当一个子图模式发布到提案的源变体包含变更，这些变更处于已批准、 公开征求意见或 草稿提案中时，相应的发布会显示在提案的活动日志中。

当一个已批准或 公开征求意见的提案的所有变更已经完全实施——无论是一次还是多次发布——该提案的状态将变为已实施。