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

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

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

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

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

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

场景和对应解决方案：

  1. 代码库有使用 submodule 代码拉不下来，git submodule update 一直卡住不动：推荐系统配置里面使用代理
  2. GitHub 代码库经常出现拉下来代码：推荐系统配置里面使用代理
  3. 代码构建中存在外部依赖，拉不下来：推荐构建脚本使用代理或者通过配置国内的源来代替

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

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

  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 之前是否使用了科学上网代理，如果设置了代理，docker build 会走代理导致失败。处理方法：在 docker build 之前加上以下命令

  1. unset http_proxy https_proxy