问题标签 [to-be-continuous]

我们在 Orange 有一份 to-be-continuous 的副本，目前使用如下：

但是我不知道同步如何与 Orange repo 一起工作，我认为最好让所有项目直接包含 gitlab.com 链接，以便更快地访问新功能，你怎么看，你期待任何问题，安全还是运营明智？

按照此处的说明，我正在尝试持续启动和运行。

我创建了空的待连续根组和维护者非个人 GitLab 帐户，并生成了其适当范围的个人访问令牌。

在执行 curl 命令以递归方式复制 tbc 组时，我注意到工具子组没有被克隆。

看到下一步需要从 tools 组跟踪 repo，我手动创建了 tools 子组，并单独手动克隆了它下的每个 repo，有效地镜像了权威 tbc repo 的结构和内容。

此外，我在 OpenShift GitLab 运行器中配置了我自托管的 GitLab 的 CA，这样我就不再遇到 x509 错误。

有了上述内容，包括我的 OpenShift 集群上可用的 GitLab 运行器，我尝试手动运行跟踪 repo 的管道（据我所知，这是任何其他管道运行的先决条件？）。

GitLab 跑步者似乎拿起了管道，因为跑步者的日志滚动了以下内容：

同时，GitLab 上的流水线日志显示如下：

花了好几个小时才走到这一步，我很难过。知道我做错了什么吗？

根据要求添加了 kaniko 日志：

我想知道为什么 to-be-continuous/terraform 模板中的“tf-plan-production”作业是唯一在合并请求管道上运行的作业？
有人知道这背后的原因吗？
因为我发现有 2 个管道令人不安，1 个分离的管道仅包含一个作业，而另一个管道包含所有其他作业（tf-plan-review、tf-tflint、tf-checkov ...）。我犹豫要否决这条规则，因为我可能会错过一些重要的事情。

更准确地说，在这个待连续模板中，所有定义的作业都不会使用规则在合并请求管道上运行：

除了具有以下规则的“tf-plan-production”作业：

我在尝试将 Hashicorp 保险库模板（带有 Google Kubernetes Engine 的 kubernetes）与 to.be.continuous 一起使用时遇到了一些问题。

实际上，当我将它与Google Docker Kaniko 层一起使用时，我收到一条错误消息：... wget: bad address 'vault-secrets-provider'。

Kaniko 似乎无法识别 vault-secrets-provider 层。你能帮我解决这个问题吗？或者，我可以在哪里寻求帮助？

这是 .gitlab-ci.yml 的总结

错误信息：

我在没有 Vault 层的情况下直接尝试了很多次，并且 Kaniko 工作正常，我的意思是没有 Vault 机密。

我怎么能做到这一点？我尝试修改 kaniko 模板但没有成功。

我将不胜感激这方面的任何帮助。

我在尝试使用 Hashicorp 保险库模板（使用 terraform to.be.continuous）时遇到了一些问题。

实际上，当我将它与 terraform-vault 模板一起使用时，我收到了一条错误消息。

这是 .gitlab-ci.yml 的总结

错误信息：

我试过没有保险库模板，它可以工作。

你能帮我解决这个问题吗？或者，我可以在哪里寻求帮助？