2024.09.21
ToDo
Knowledge
-
python enum
-
python r"" f""
-
python writelines
工作内容
patch unity
-
描述
添加 USE_DEBUG_IL2CPP 开关至 BuildAll_new 流水线，但是发现还原目录跟已有的一个 patch 是一样的，沟通之后重新整理了需求
-
把之前 il2cpp 相关的单个 patch 开关改成多选一模式选择性替换patch目录
-
重构了之前 il2cpp 相关的patch参数，全部做了新的逻辑分歧和翻译，改动比较多，上午改完之后检查了没问题，中午做了提交
-
完成了使用对接和交付，后半天已经开始使用了
长期归档版本
-
之前归档目录只有一个 bvt，后续可能有展会等一些重要节点的版本需要长期保存，新增了构建参数支持多选一归档目录
-
新增了归档备忘日志，客户端和服务器版本目录各存有一个归档版本备忘说明文件
脚本验证
昨天看客户端脚本的时候发现有些逻辑没走到。
client.7z 在 PreBuild.py 中并没有用到
验证现场：
前面的流程中导出上传的 client.7z 没在这里解压使用，还有待查证
后处理报错
当上一次执行成功的步骤是 PRE_BUILD ，那么不进行 process_error
对应流水线：
当构建前准备执行成功，Unity构建失败时，是不会进入上述的 prcess_error 的
今天看了一下报错处理流程，编译报错的处理，通过后面检查构建是否完整来判定构建失败，从而提取编译日志发送消息
服务端相关构建
同昨天看客户端构建一样，今天也细看了一下服务端构建
-
服务端总计分为 RoomServer 和 MechaServer 两种服务端；
前者存在3种 Win Server编译版本、6种 Linux server构建版本
后者又分了两种Win编译版本和两种Linux编译版本
-
构建目录因不同集群和不同平台有所不同，大致的流程是类似的
先拉取 Server 目录 和 Runtime 目录
编译，Runtime中生成编译产物
将产物压缩收集至 build_temp，包括 exe、assembly、符号以及一些记录文件等
将压缩包上传至188/189指定目录，最终成品就传188，中间件就传189
服务器 gameshared.dll 版本不对应问题
问题描述：BuildAll 构建出来的服务端 gameshared 不是最新的，版本过旧
正好看了相关的构建流程
简单分析了一下：
-
客户端的gameshared.dll都是根据构建指定的 svn ver 做了对应的
-
服务端的 gameshared 没有根据 svn ver 做对应，而且也没用到构建流程中的gameshared（大概率没编），而是采用了代码提交实时编译出来的 gameshared 版本，而且也没核对版本
因为代码提交实时编译提交，流程阻塞容易造成排队，所以很容易导致 BuildAll 构建出来了服务端，但是代码实时提交编译还没出来对应版本的 gameshared，最重要的是也没核对版本，这部分还要核实一下，具体的流程需要梳理
待办
-
gameshared 不对版的问题
-
client.7z相关的应用