2024.09.19

发表于 更新于 分类于 阅读次数： 本文字数： 974 阅读时长 ≈ 4 分钟
Thu | 八月十七 | 甲辰癸酉丙戌

以后要早上8点出门，不然出来找车要20分，到公司上楼要10分，中途骑车10分，8点半出门，9点根本到不了公司

SeasunDay6

Narrate

  • MAUI

昨天骑车到小区旁边，今天出门把车骑回楼下，方便宝贝上班。

ToDo

  • 服务器构建流程

  • 加密，渠道部署

  • 文件服务器分流

Knowledge

工作内容

清理cache完善收尾

因为构建可能失败，如果构建失败了，project-library不会归档到cache-library

所以，完善了一下逻辑：优先寻找 cache-library 目录清理，如果构建失败没有备份出去，那么就寻找project-library进行清理。

考虑到 如果bundle缓存出错，可能也会导致构建失败，这种情况也是应用清理缓存工具的情境。

阅读流水线

看了服务器相关的构建流水线内容 —— roomserver & mechaserver

信息完善和总结

很多时候构建资源工具相关的信息不能迅速查询到，阻碍了查问题的速度，所以做了一些信息完善和总结

  • 蓝盾流水线里面的 任务节点 是可以看到调用的哪个python脚本，但是看python脚本逻辑的时候，很难寻找到对应的流水线，看一下执行场景和参数。

所以把看过的脚本都添加了对应的流水线信息：(格式如下)

1
# pipeline - PipelineName - PipelineLink

  • 总结了一些目录信息（未完待续）

  • 总结了一些构建机的信息（未完待续）

get library bat 拉取文件严重过期问题

  • 反馈现场

mecha-download2.seasungame.com 下载的 Library.7z 是4月份的

  • 猜测一：209 服务器上文件本身是旧的

  • 验证一：验证失败

189、207、209 文件显示时间都是最新

  • 猜测二：209文件服务器从189下载覆盖文件存在问题

  • 验证二：验证失败

download的逻辑是先删除本地然后下载，所以不存在覆盖失败的问题

  • 猜测三：上传下载参数和逻辑都验证过之后，猜测客户端侧使用的脚本链接有问题

链接解析出来也是符合预期的，但是唯一的问题就是，链接的地址是否对应的是我们查证的 /data/UnityLibrary 目录

  • 验证三：验证成功

链接默认访问的是 /data/autobuild/ 目录下的 UnityLibrary，而 Library 文件同步传输的目录是 /data/UnityLibrary

  • 验证步骤：

    • 首先查证了 nginx 的 server路径配置，没有发现有效信息
    • 然后全局搜索了 Library.7z 这个文件，发现了我们熟悉的一个目录 /data/autobuild/ 下也有一个压缩包
    • 将zip下载脚本中的 路径重新设置之后，问题解决

  • 总结

看流水线逻辑的时候，为了验证数据文件流转，都要到对应的构建机上查证的，有问题会跟 zilve 沟通请教，但是这次这个问题是在同一个根目录下 /data 存在 /autobuild/UnityLibrary 和 /UnityLibrary ，因为 189 中的 UnityLibray是在 /data/shared/ 目录下，下载逻辑里也是 /data 根目录 UnityLibrary，都是很统一的目录结构，没想到链接默认是 autobuild 的。

问题查询之后，就把 207 和 209 的 /data/UnityLibrary/trunk 删除了，其余部分依旧保留，待观察几天后没有新的文件产生再将上层目录删除

权限开通

所有 服务器 权限均已开通，均可登录，包括 188

待办

  • 阅读构建后续整合流程、部署加密等

  • 完善信息表

  • unity 定制版编译相关的小功能需求

  • 188构建机卡顿