Capgo Pull Request Preview Cleanup API Key

删除预览请求看起来像一项命令工作。然而 Capgo然而，有一个陷阱：您必须在删除预览之前切换到活动预览，然后通过 ID 删除其捆绑包。我们将构建一个安全的清理流程，具有受限的 API 密钥、预览查找、重置处理、捆绑包删除和 CI 自动化。

步骤 1：为预览清理创建受限的 Capgo API 密钥
步骤 2：确定预览请求和其捆绑包 ID
步骤 3：在清理之前切换到活动预览
步骤 4：使用 API 密钥通过 ID 删除预览捆绑包
步骤 5：在预览请求关闭时自动清理
步骤 6：验证清理并防止意外删除
常见问题
结论

步骤 1：创建一个受限的 Capgo API 预览清理密钥

在 Capgo pull request 预览清理流程中，第一步是创建一个可以只执行 CI 任务所需工作的密钥

不要将广泛的组织密钥放入 pull request 工作流中。pull request 可以来自尚未获得信任的分支。工作流程也可能在失败运行时打印命令或环境值。有限的密钥可以限制如果发生这种情况的损害。

在 Capgo 中，首先使用 App Preview 密钥进行预览工作。密钥应与管理的应用或预览范围相关联。如果您的团队使用基于角色的访问控制，限制密钥仅限于选定的应用，而不是授予整个组织的访问权限。 Capgo 文档了这些预览密钥的选择 API 的 Web 应用工作流密钥设置.

将密钥存储在 CI 提供商的加密密钥存储中。给它一个描述其用途的名称，例如CAPGO_PREVIEW_CLEANUP_KEY不要将其放入工作流文件、shell 脚本、pull request 评论或生成的日志中。

将密钥传递给清理过程，通过环境变量。脚本应在变量缺失时失败。静默回退是危险的，因为它可以将清理任务转换为无授权请求，或者诱使开发人员将密钥粘贴到命令行中。

if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fi

请将此密钥与用于发布生产包的密钥分开。发布作业可能需要上传一个发布版本。清理作业只需删除预览资源。分开的密钥使审查更容易，并减少删除操作到达生产频道的机会。

在保护环境中尽可能使用相同的密钥。要求在共享频道之前审批作业。对于普通拉取请求预览，作业应在临时频道上工作并且什么也别动。

关键点: 使用专用的App预览密钥，限制其应用范围，并将其存储在加密的CI密钥中。

在继续之前，测试密钥对无害的读取操作。确认作业可以看到预期的应用，但不能访问未相关的应用或生产工作流。清理详细信息尚未完全发布，因此请在添加删除调用之前先进行小规模测试并检查SDK或Capgo支持指导。

步骤2：识别拉取请求预览及其包ID

Capgo的Capgo pull request预览清理API密钥仅在您的作业知道它拥有的预览和捆绑ID时才有用。

只有当您的作业知道哪些预览和包ID属于它时，__CAPGO_KEEP_0__拉取请求预览清理__CAPGO_KEEP_1__密钥才有用。

创建预览时保存预览频道名称。您可以将其放入工作流输出、拉取请求检查或小型作业元数据中。不要依赖于可能在控制台中更改的显示名称。

接下来，列出与该预览关联的包。Capgo的删除包操作需要包ID。源文档指向一个列表调用以获取所有可用包ID以便删除。将该列表视为真实来源。不要猜测ID从文件名、提交哈希或分支名中。

过滤返回的记录根据预览频道或您的工作流控制的另一个值。然后保留每个匹配的确切包ID。如果列表为空，标记清理为完成。一个空结果不是失败，除非您的工作流期望预览存在。

也记录产生每个预览的提交SHA。这给你第二个检查删除之前。频道名称匹配但提交不匹配时，停止并要求审查。这个小暂停可以防止一个竞争场景，其中一个新预览正在构建，而一个旧清理作业正在运行。

Capgo拉取请求预览频道和包ID清理

不要在发布作业仍在运行时删除。添加一个依赖项之间的预览构建和清理工作流，或者使用一个与拉取请求号相关的锁。清理作业应该在关闭事件发生并任何挂起的预览上传结束后才开始。

Capgo的公共API Capgo公共API概述确认当前资源模型

您应该已经有一个预览标识符、一个精确的包ID列表以及每个记录关联的提交SHA。如果其中一个值缺失，请停止。在没有拥有权检查的情况下清理是猜测。

步骤3：在清理之前切换到非活动预览

一个活动预览不能在应用程序切换到它或调用之前被删除。这是__CAPGO_KEEP_0__ pull request预览清理流程中的关键细节。resetPreview活动预览可以看作当前应用程序选择的版本。删除服务器端记录首先会使应用程序指向不存在的东西。 Capgo阻止这种状态变化，因此您的清理任务必须在删除预览之前重置应用程序的预览状态。

Think of the active preview as the version currently selected by the app. Deleting the server-side record first would leave the app pointing at something that no longer exists. Capgo blocks that state change, so your cleanup job must reset the app’s preview state before it removes the preview.

使用

UseresetPreview当预览状态需要立即清除时。将此调用与创建预览的相同拉取请求和应用程序绑定。清除脚本不应仅因为通道名称匹配而重置生产设备或共享发布频道。

这里有一个有用的排序规则：

确认拉取请求已关闭。
确认没有正在运行的预览上传。
切换到非活动预览或调用resetPreview.
等待该状态更改完成。
只有在此之后才能调用删除预览。

不要将重置请求的成功 HTTP 响应视为应用程序已经在每个设备上更改状态的证据。设备可能会稍后检查更新。您的服务器端清理可以在预览分配已根据API响应清除后继续进行，但请将设备行为与资源删除分开。

Capgo支持基于通道的发布控制，这使得这种分离更容易理解。通道是指告诉应用程序哪个更新流程的名称路径。您的预览通道不应与生产设备使用的通道相同。

对于需要更严格边界的团队，请使用文档的 Capgo预览自动化通道工作流。它描述了临时通道模式并有助于保持清理作业与共享默认通道分开。

开源更新器文档还记录了删除限制：活动预览需要切换或重置。您可以在Capgo Capacitor更新器仓库中查看源代码。该源代码在仪表盘词汇太简短时有用以做出CI决策。

Pro Tip： 重置为单独的记录步骤。删除预览失败时，日志应显示预览是否仍然活动还是删除请求有其他问题。

一旦活动状态消失，预览记录就可以删除了。不要将重置和删除合并为一个不透明的shell命令。两个清晰的命令更容易重试，并且更容易审计。

步骤 4：使用API密钥删除预览包

删除每个预览包的确切 ID，等待活动预览被重置。Capgo清理密钥可以移除 pull 请求留下的存储对象。

从步骤 2 的包列表开始。对于每个匹配 ID，通过Capgo SDK或当前公共API方法调用删除包动作。

检查SDK方法签名或确认当前请求形状与Capgo支持。记录方法和响应格式在团队的内部运行书中。该运行书应包括API版本、所需标识符和重试逻辑可以处理的错误代码。

在脚本中使用 dry-run 模式。它应该打印预览频道和它将删除的包 ID，而不发送删除请求。将该模式应用于几个关闭的 pull 请求。检查它排除了生产频道，并且它不会将空列表视为通配符。

安全删除循环有三个门槛：

拒绝缺失或错误的包 ID。
拒绝包 ID 的频道不匹配 pull 请求预览。
只有所有权检查通过后才删除。

然后根据响应类型处理每个响应。成功删除可以记录为完成。未找到响应可以视为已清洁，如果资源已知被早期重试删除，则可以处理。权限错误应该失败任务并警告拥有者。速率限制应该暂停并在带有最大延迟的重试中。

不要重试每个错误。一个坏 ID 在三次尝试后不会变成有效的 ID。授权错误通常意味着密钥范围错误。只重试暂时性失败，并设置最大运行时间以防止 CI 队列中的卡住的清理任务消耗资源。

包删除与预览删除是分开的。删除预览频道并不自动证明每个包都已删除。您的任务应该保留每个 ID 的结果，然后如果 API 支持则进行最后一次列表请求。如果任何包仍然存在，则报告 ID 并停止，而不是默默地声称成功。

保持删除日志免受机密信息的污染。可以记录pull请求号、预览名称、包ID、请求结果和时间戳。绝不记录API密钥、授权头或可能包含其中的完整请求对象。

这种方法为您提供了有用的审计记录，而不会将日志转变为另一个可能泄露凭据的地方。它还使失败的清理变得容易恢复，因为下一次运行可以跳过已经确认为不存在的记录。

步骤 5：在 pull 请求关闭时自动清理

从 pull 请求关闭事件中运行清理作业，但添加检查以防止晚期构建删除新预览。

您的工作流程应从事件负载中接收仓库和 pull 请求号。从这些值重建预览频道名称。不要接受由 pull 请求评论或不信任的 branch 变量提供的频道名称。

一个有用的作业序列如下：

从加密密钥中加载受限清理密钥。
确认事件是关闭的 pull 请求。
检查预览属于预期的仓库和应用。
等待任何活动预览部署完成。
切换到预览或调用resetPreview.
列出该预览的包ID。
删除每个已验证的包。
删除预览记录。
将结果写入工作流程摘要中。

顺序很重要。如果你先删除，活跃的预览规则可能会阻止请求。如果你跳过列表调用，你可能不知道哪些包 ID 还存在。如果你通过猜测的名称删除，你有风险触摸错误的资源。

pull request 预览清理的自动化 CI/CD 工作流程

使用一个与 pull request 号码相关的并发规则。当一个关闭事件和一个重建事件在同一时间到达时，旧的清理作业不应与新部署竞争。取消过时的清理作业或让作业等待部署锁清除。

Capgo 的一条命令 CLI 工作流程可以减少自定义 shell 命令的数量，围绕构建和发布工作。有关命令名称和支持的操作，请参阅 Capgo CLI 命令文档。使用 CLI 时，它给你一个已验证的命令。使用 SDK 或公共 API 时，清理动作需要直接请求。

不要将清理放入每次推送都会运行的工作流程中。推送作业可以删除正在测试的预览。关闭事件是正常清理的正确触发器。添加一个手动工作流程调度以恢复当作业失败时。

设置一个保留fallback。如果关闭事件被错过，一个预定的作业可以找到比团队允许的测试窗口更旧的预览。该作业需要比正常关闭钩子更严格的安全措施。它应该只选择有明确的拥有者并且过期的时间戳的预览。

对于 GitHub 动作，保持权限狭窄并仅传递清理步骤所需的值。 Capgo 的当前 GitHub 动作集成文档解释了令牌存储的位置以及工作流如何连接到 Capgo。

到目前为止，您应该已经有一个自动化路径来响应关闭，等待竞争作业，重置活动状态，列出 ID，并仅删除匹配的捆绑包。这足够快，不会让清理成为盲目的扫把。

第 6 步：验证清理并保护发布从意外删除中保护

验证关闭了 Capgo pull 请求预览清理循环。仅有删除响应不足以确保安全发布过程。

清理作业运行后，请检查预览频道。确认它不再作为活动预览出现。然后检查同一应用程序和过滤器的捆绑包列表。预期结果是目标捆绑包 ID 已消失，而生产捆绑包仍然存在。

保存这些值在作业摘要中：

仓库和 pull 请求号。
预览频道名称。
用于所有权检查的提交 SHA。
找到的捆绑包 ID。
删除的捆绑包 ID。
返回错误的 ID。

使用明确的状态。 “Cleaned”意味着所有已验证的目标都已消失。 “Already clean”意味着资源在此次运行之前就不存在。 “Needs review”意味着一个或多个检查失败。不要将部分删除标记为成功。

在code中添加一个生产保护机制。拒绝类似于默认或发布渠道的渠道名称。同样，拒绝一个包如果其元数据与预览应用不匹配。保护机制应关闭失败。当脚本无法以信心确定目标时，它应停止。

将回滚与清理分开。回滚会改变设备接收的包。清理会删除旧的预览资源。如果测试在pull request关闭后发现了bug，您可能需要包来进行调查。设置一个短的保留窗口而不是立即删除事件到达时。如果您的团队经常在合并后调试，建议这样做。

注意三个常见的失败模式：

活动预览错误： 重置或切换到其他选项之前重试删除预览。
缺少包ID： 再次运行列表操作，而不是猜测。
权限错误： 查看密钥范围，然后如果需要，发出新的密钥。

定期根据您的安全策略轮换清理密钥，并立即轮换如果它出现在日志或提交中。新密钥应在旧密钥被撤销之前进行测试，除非暴露需要立即撤销。

安全审查中，清理文档的缺口值得一笔。将SDK和Capgo的验证指南视为实现的来源，并将自己的请求协议纳入版本控制。

关键 takeaway: 删除后，验证预览和捆绑列表，阻止code中的生产目标，并报告部分清理为失败。

只有当护栏清晰时，才有用的一条命令是跟踪预览。采用可预测的频道名称。单独回滚发布更改。然后，让清理作业做它的小工作，而不触摸实时流量。

FAQ

是否可以删除一个活跃的Capgo pull request预览？

是否可以删除一个活跃的__CAPGO_KEEP_0__ pull request预览？resetPreview否。必须先切换到非活跃状态，或者调用。等到活跃状态清除后，运行删除预览。这条规则是设置Capgo pull request预览清理API密钥的主要细节。

是否需要捆绑ID来清理一个Capgo预览？

是。Capgo的删除捆绑动作需要捆绑ID，因此在删除之前列出可用的捆绑。匹配每个ID到预览频道和提交，然后发送删除请求。不要从分支名称构建ID，也不要假设删除预览也会删除所有捆绑。

CI应该使用什么样的API密钥来清理预览？

使用受限的 App 预览密钥进行预览清理，存储在您的 CI 提供商的加密机密存储中。限制密钥仅限于应用程序或范围内。将其与用于发布生产更新的密钥分开。这使得 Capgo 清理作业更容易审查和更安全地旋转。

我可以自动清理关闭的拉取请求吗？

是的。从关闭的拉取请求事件触发清理，然后等待活动部署作业重置预览。列出捆绑 ID，删除验证匹配项，并确认结果。添加并发控制，以便晚期构建不能与清理作业竞争。

为什么我的 Capgo 清理请求失败了？

通常原因是活动预览、缺少捆绑 ID 或密钥没有所需的范围。首先重置预览，然后重复列表调用并检查密钥权限。由于请求详细信息可能因 API 或 SDK 版本而异，请在更改脚本之前确认当前方法和参数。

结论

使用 Capgo 与专用预览密钥和严格清理顺序：重置活动预览，列出其捆绑 ID，删除验证捆绑，然后删除预览。从一个关闭的拉取请求开始进行干净的运行，确认当前 SDK 中的请求形状，并在自动清理开启之前添加生产通道守卫。