笔记

• 平台构建需要很长时间（超过 1 小时）。开发人员应该更快地获得有关他们工作的测试反馈。我们是否需要为每个 PR 的每个提交构建 3xLinux + Mac + 2xWin？
• 一份类似的报告提到了一个丢失的 webhook。Appveyor 是如何添加到这个 repo 中的？它是否缺少pull_request webhook？
• appveyor.yaml 中有一个明文安全令牌

在探测安全令牌的权限和可利用性时，Github API 响应为 401 Unauthorized。这个令牌可能在某个时候起作用，并且可能因为它不正确地存储在明文 VCS 中，它被滥用或被 Github 本身作为安全措施撤销。

整治

• 在 Github 中重新发布安全令牌
• 将此令牌添加到 Appveyor 中的环境变量：https ://ci.appveyor.com/project/cncjs/cncjs/settings/environment （此处猜测 URL）
• 将 appveyor.yaml 中的令牌用法转换为与 Appveyor env vars 中设置的名称匹配的环境变量

问题

• 如果将 Appveyor 安装为 Github 应用程序，是否真的需要此令牌？

下一步

• 等待 40m 构建完成以查看状态是否正确报告测试更改以触发 CI  emcniece/cncjs#1

使用 Github 插件安装方法使用基本的 Appveyor 设置在emcniece#1上复制了错误行为。

即使具有提升的 Appveyor 管理员权限，似乎也没有任何日志记录来指示此失败。

通过编辑 appveyor.yaml 继续进行故障排除：删除长构建步骤和部署块。

一段时间后，emcniece#1的初始构建成功了——我认为这与未经授权的部署令牌无关。

查看 Appveyor 发布的 Github 状态，continuous-integration/appveyor/pr构建拉取请求并continuous-integration/appveyor/branch构建master分支。每次更新拉取请求时都会触发这些构建。构建大约需要一个小时，在 Appveyor 的免费套餐下，该项目一次只允许构建一个。这为具有许多分支、拉取请求和提交的项目创建了相当长的队列。

排长队很不方便，但对于这个问题来说，它们是一个转移注意力的问题——必须修复最新的分支构建，这样 Appveyor 才能在所有开放的 PR 上报告成功。

奇怪的是，正在进行的状态不包含指向活动 Appveyor 构建的链接，Appveyor 更新特定状态的方式肯定出了问题。有问题的状态都是为了重建master分支。Appveyor 项目历史可能有一些信息，我们将不得不挖掘列表以找到将构建与 PR 相关联的方法。

接下来，我将使用无操作 PR 测试新的 CI 构建。

有趣 – 在emcniece#1中，两个构建 (/branch和/pr) 都立即排队，并且都有指向 Appveyor 的链接。在#748中，只有/pr构建获得链接，并且https://ci.appveyor.com/project/cheton/cncjs/history/branch没有显示将构建添加到队列的意图。

我怀疑 Appveyor 项目设置已被更改以创建此行为，或者项目遇到了一些计划限制。

@MitchBradley您能帮助确认https://ci.appveyor.com/project/cheton/cncjs/settings上的设置有任何差异吗？我将发布我成功配置的屏幕截图：

第 1 节：

第 2 节：

第 3 节：

我似乎没有该 Appveyor 帐户的权限。我在 cncjs repo 上的会员身份似乎没有扩展到 appveyor 设置。我会尝试得到@cheton涉及。他在台湾，所以可能要过一段时间才能上网。

谢谢@MitchBradley. 我想知道你是否可以再检查一件事：

master是否在https://github.com/cncjs/cncjs/settings/branches的分支保护设置中将“continuous-integration/appveyor/branch”设置为预期检查？

如果是，我们可能会看到 Github 在 Appveyor 使用构建链接更新相同状态之前添加了待定状态。我们还应该看到 Appveyor 已配置为不在master上面第 1 节屏幕截图的设置中构建分支。

一种解决方法是删除该分支保护状态规则。另一个修复可能是master在 Appveyor 设置中恢复分支构建。

你好@emcniece @MitchBradley

continuous-integration/appveyor/branch我刚刚从 master 分支中删除了状态检查。现在您不会被不需要的状态检查所阻止。

谢谢@cheton这很棒！

当你关注这个主题时，我能问一下这个项目的 CI 愿景是什么吗？我在 PR 中看到许多不同的平台和状态检查。我想知道您是否愿意巩固和改进这些管道和交付流程。

我从 Travis CI 切换到 Appveyor 和 CircleCI，因为 Travis CI 已经转变为付费模式，它对 OSS 项目不友好，尤其是当你必须进行 macOS 构建时。

对于这个 repo，我将 CircleCI 和 Appveyor 用于不同的目的：

• CircleCI 配置 ( https://github.com/cncjs/cncjs/blob/master/.circleci/config.yml ) 将仅在创建标签时运行工作流。其目的是构建 Docker 映像并将其部署到 Docker Hub ( https://hub.docker.com/r/cncjs/cncjs/tags )。

• Appveyor 配置 ( https://github.com/cncjs/cncjs/blob/master/appveyor.yml ) 将触发 Linux、macOS 和 Windows 环境的 PR 和 master 分支构建。安装程序工件将在 CI 阶段创建，但仅当主分支更新或创建标签发布版本时，资产才会上传到GitHub Releases 。

  

感谢您的简要介绍。既然我们已经弄清楚了神秘状态，就把问题标记为已关闭！