Go mod 构建时使用了代理,拉取 pkg 时直接报 Too many connection,如何解决?
代理服务器连接数太多导致的,可以请求运维人员协助排查,或者优化代理服务器配置,采用透明代理的方式减少连接数。
前端本地构建正常,线上构建 package.json 报错,无法拉取相关依赖,该如何解决?
按照如下流程去逐步排查:
- 检查 package.json 是否存在私有依赖,存在则确定是否有相关读取权限
- 确认构建脚本是否和本地相同
- 检查构建中应用的版本是否与本地构建的相符,排除应用版本问题
工作流某次任务的构建时间过长或者卡住了,该如何解决?
场景和对应解决方案:
- 代码库有使用 submodule 代码拉不下来,git submodule update 一直卡住不动:推荐系统配置里面使用代理
- GitHub 代码库经常出现拉下来代码:推荐系统配置里面使用代理
- 代码构建中存在外部依赖,拉不下来:推荐构建脚本使用代理或者通过配置国内的源来代替
构建里面某个包一直无法上传到对象存储问题诊断
按照如下流程去逐步排查:
- 检查本次构建是否构建选错了分支以及 PR
- 检查本次构建脚本中上传相关的业务工具的参数是否配置正常
- 确认第三方存储服务一直处于正常可用状态
- 请求运维人员协助确认当前集群所在的节点是否存在网络解析故障
镜像推送失败问题诊断
可以按照以下流程逐一排查:
- 确认所使用的镜像仓库网络连通且功能可用
- 确认所使用的镜像仓库是否设置了默认最大镜像数,可能镜像数达到了上限
工作流-构建报错诊断
no cotainer statuses : s-task=pipelineName-548,s-service=serviceName,s-type=buildv2,p-type=workflow
可以查看一下具体的 Job 的状态以及 Job 的日志,具体操作如下:
kubectl get pod -n <namespace> |grep <pipelineName>
#找到对应的 Pod 后可以查看下具体的 Pod 的日志
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 之前加上以下命令
unset http_proxy https_proxy
Webhook 触发器配置失败
在 Zadig v1.3+ 中,使用 GitLab 14.0+ 在工作流中配置 webhook 触发器的时候可能会提示以下信息:
400 : 新建或更新wokflow失败 1 error occurred: * POST http://gitlab....com/api/v4/projects/owner+repo/hooks: 422 {error: Invalid url given}
这是 GitLab 的配置问题,使用如下配置即可解决问题。详见:https://gitlab.com/gitlab-org/gitlab/-/issues/25867