账号登录不了

1.7.0 以下版本，系统账号无法登录，报错 504

查看当前 pd-web 服务的状态和日志，确认和数据库服务连接是否存在异常。命令如下：

  1. kubectl get pod -n < koderover 所在的 namespace > |grep <pd-web>
  2. #找到对应的 Pod 后可以查看下具体的 Pod 的日志
  3. kubectl logs -f <pod/podName> -n <koderover 所在的 namespace >

1.7.0 及以上版本，系统账号无法登录

如果集成了 AD/LDAP/SSO，请确认集群内的网络是否可以正常连接 AD/LDAP/SSO 系统。

Go mod 构建时使用了代理，拉取 pkg 时直接报 Too many connection，如何解决？

代理服务器连接数太多导致的，可以请求运维人员协助排查，或者优化代理服务器配置，采用透明代理的方式减少连接数。

前端本地构建正常，线上构建 package.json 报错，无法拉取相关依赖，该如何解决？

按照如下流程去逐步排查：

  1. 检查 package.json 是否存在私有依赖，存在则确定是否有相关读取权限
  2. 确认构建脚本是否和本地相同
  3. 检查构建中应用的版本是否与本地构建的相符，排除应用版本问题

工作流某次任务的构建时间过长或者卡住了，该如何解决？

场景和对应解决思路：

  1. 代码库有使用 submodule 代码拉不下来，git submodule update 一直卡住不动：推荐系统配置里面使用 Proxy，参考：Proxy 设置
  2. 经常出现拉不下来 GitHub 代码：推荐系统配置里面使用 Proxy
  3. 代码构建中存在外部依赖，拉不下来：推荐构建脚本使用 Proxy 或者通过配置国内的源来代替
  4. 触发工作流任务后就卡住了，工作流实时构建日志没有输出：按照以下步骤排查
  1. # 1. 查询状态异常的 Pod
  2. kubectl get pod -n <namespace>
  4. # 2. 查看异常状态 Pod 的详细信息
  5. kubectl describe pod <podName> -n <namespace>

构建里面某个包一直无法上传到对象存储问题诊断

按照如下流程去逐步排查：

  1. 检查本次构建是否构建选错了分支以及 PR
  2. 检查本次构建脚本中上传相关的业务工具的参数是否配置正常
  3. 确认第三方存储服务一直处于正常可用状态
  4. 请求运维人员协助确认当前集群所在的节点是否存在网络解析故障

镜像推送失败问题诊断

可以按照以下流程逐一排查：

  1. 确认所使用的镜像仓库网络连通且功能可用
  2. 确认所使用的镜像仓库是否设置了默认最大镜像数，可能镜像数达到了上限

工作流-构建报错诊断

no cotainer statuses : s-task=pipelineName-548,s-service=serviceName,s-type=buildv2,p-type=workflow

可以查看一下具体的 Job 的状态以及 Job 的日志，具体操作如下：

  1. kubectl get pod -n <namespace> |grep <pipelineName>
  2. #找到对应的 Pod 后可以查看下具体的 Pod 的日志
  3. kubectl logs -f <pod/podName> -n <namespace>

no space left on device

这个是 Zadig 系统的 spock-dind 服务挂载的 pvc 的空间不足导致的，可以使用我们系统设置-系统配置-缓存清理功能一键清理这些数据，详见缓存清理

Failed parsing or buffering the chunk-encoded client body

镜像构建报错

执行构建任务出现以上错误时，需要确认 docker build 之前是否设置了 http_proxy 和 https_proxy，如果设置了 Proxy，docker build 会走 Proxy 导致失败。处理方法：在 docker build 构建之前加上以下命令

  1. unset http_proxy https_proxy

500:Internal Error:-148643:action not allow status code:403 ...

执行构建任务出现以上错误，需要确认集成的默认对象存储是否放开上传、下载、删除文件、列出文件列表权限。

Webhook 触发器配置失败

POST http://gitlab....com/api/v4/projects/owner+repo/hooks: 422 {error: Invalid url given}

在 Zadig v1.3+ 的版本中，使用 GitLab 14.0+ 在工作流中配置 Webhook 触发器的时候如果提示以下信息：

  1. 400 : 新建或更新wokflow失败 1 error occurred: * POST http://gitlab....com/api/v4/projects/owner+repo/hooks: 422 {error: Invalid url given}

这是 GitLab 的配置问题，使用如下配置即可解决问题。详见：allow_local_requests_from_hooks_and_services诊断手册 - 图2 (opens new window) GitLab 配置

Hook executed successfully but returned HTTP 404 Invalid path: /api/gitlabhook

在 GitLab 中手动添加 Webhook 时报错如下：

  1. Hook executed successfully but returned HTTP 404 Invalid path: /api/gitlabhook

在 Zadig 1.3.0 及以上版本中该接口已下线，在工作流里配置触发器后无需再在 GitLab 系统中手动添加 Webhook 设置。 在 Zadig 系统登录页面下方，可查询版本信息，见下图：

查看 Zadig 系统版本

Webhook 触发器配置后不生效，有什么排查思路？

配置 Webhook 触发器时没有明显报错，但有代码变更时触发器功能不生效。以下提供几种常见排查思路。

在 Zadig 平台检查 Webhook 配置

编辑具体的工作流，切换到顶栏的触发器查看 Webhook 配置细节，确保代码的变更符合触发条件。配置中各参数说明可参考Webhook 配置。

检查工作流中触发器配置

在 GitHub 代码仓库检查 Webhook 配置

  • 访问具体的 GitHub 代码仓库 - Settings - Webhooks 可查看当前项目的 Webhook 配置列表。

检查 GitHub 中触发器配置

  • 在 Settings 中查看 Webhook 的具体配置，在 Recent Deliveries 中可查看最近的 Webhook Event 及状态。

检查 GitHub 中触发器配置

在 GitLab 代码仓库检查 Webhook 配置

  • 访问具体的 GitLab 代码仓库 - Settings - Webhooks 可查看当前项目的 Webhook 配置列表。

检查 GitLab 中触发器配置

  • Test 操作可对 Webhook 设置进行测试，点击 Edit 可查看最近的 Webhook Event 及状态。 检查 GitLab 中触发器配置