docker 版本的 console 之前一直不显示 build
因为 workflow 没往里面传参

这样的话就自动被解决了呗

之前加上 buildvcs=false 原因也不是省空间（那么一点作用不大，不如清理陈旧代码来得多），主要是考虑到在 VCS 信息源丢失/损坏或者各种奇奇怪怪的原因无法获得的时候至少不会太影响可重复构建；再者是考虑到有可能会出现偶发性的局部发版故障，只有一两个需要补发的情况下补包时对仓库的修改会导致提交 hash 变化的问题（可以通过硬性指定拉取代码的 hash 解决）。

这几个好办的话那么加回来问题似乎也不大。

之前加上 buildvcs=false 原因也不是省空间（那么一点作用不大，不如清理陈旧代码来得多），主要是考虑到在 VCS 信息源丢失/损坏或者各种奇奇怪怪的原因无法获得的时候至少不会太影响可重复构建

buildvcs 只要命令行有git而且git目录没被剥掉就能正常工作 现在的构建脚本是用命令手动提取hash手动补进去不也是需要这俩 还是说验证可重复构建的时候手动把版本号写进去 这看起来也很淦 其实无论哪个方法都不很影响可重复构建验证 步骤稍有不同而已 没有啥合规性指标要求必须满足啥啥啥要求才算可重复构建了 能达到证明没脏东西的最终目的就行了

再者是考虑到有可能会出现偶发性的局部发版故障，只有一两个需要补发的情况下补包时对仓库的修改会导致提交 hash 变化的问题（可以通过硬性指定拉取代码的 hash 解决）。

没看明白 buildvcs 就是反馈build 时仓库的状态 当前的hash是什么它就绝对是什么 包括仓库中存在未提交变更时的-dirty后缀我都加进去了

vcs 会加哪些信息来着

vcs 会加哪些信息来着

VCS 源（例如 vcs=git）
代码版本 （vcs.revision={COMMIT HASH}）
提交时间（对应提交的编辑时间）
VCS 状态是否为有修改

以上只有在有代码版本控制信息的时候才会嵌入

没看明白 buildvcs 就是反馈build 时仓库的状态 当前的hash是什么它就绝对是什么 包括仓库中存在未提交变更时的-dirty后缀我都加进去了

局部补 release 的时候不慎引用了错的提交会导致 VCS 信息变化，因为改 actions 文件也会影响仓库代码记录，要保持一致的话要在 checkout 的时候指定提交

想起来了，这个 vcs 挺烦的就，补个 release 都不好补，维持现状吧，@KobeArthurScofield 你觉得呢

比起 Windows 版本加图标（已被毙）和要不要嵌 WinTUN 的话，VCS 信息问题倒是不那么大，但是前提是用 Git 拉代码，以及补 release 的时候手动指定提交（Actions 只管继续编译就行问题不大，现在流程不涉及代码修改也没有 Makefile 搞事了）

如果遇到了那种点右上角直接下载代码包编译的出来说文件校验不一样那才头大，因为这种情况完全没有 VCS 信息，有没有问题要用十六进制编辑器对比才知道（结果发现二进制里面就多了 VCS 信息别的一点没动）

两种都行吧，all okay，不过我觉得 Docker 确实比较需要这个（这种一般也没人哔哔可重复构建吧）

局部补 release 的时候不慎引用了错的提交会导致 VCS 信息变化，因为改 actions 文件也会影响仓库代码记录，要保持一致的话要在 checkout 的时候指定提交

我记得要在release再补一两个patch的时候不是重新跑一遍action就行了？不会在 .github 下面的action文件制造提交吧 编译出来里面嵌入的hash也是patch之后的代码

主要是自编译可以自动嵌的话方便追踪版本 因为没makefile大多数时候测试build也就一行go build还写个脚本计算一下hash再手动注入太麻烦了

首先这个 -buildvcs=false 不是为了省空间，当时加它的直接原因是有几次发了新版本后发现 workflow 要改，然后补 releases，然而就算我把 workflow 临时改成指定了显式的 core.build，仍会因为 vcs 往最终 binary 里写了一些信息导致无法 reproducible

其次我觉得 Go 默认就应该做到在任何环境下编译出来的 binary 都是一样的而不应泄露任何编译环境信息，尤其是不默认 trimpath 就很傻逼，试想一下你电脑的 username 是“zhangsan”，你放在桌面默认 go build 一下再传到网上直接就给你实名认证了

所以我从第一次编译 v2ray 开始就带了 -trimpath，但 vcs 我是不知道的，刚又问了下幸好没写 email，不然我以前上传那些 bin

谁知道它以后写不写 email，所以现有编译参数挺好的，实现了我认为 Go 默认就应该做到的事情，也为其它项目做出了示范：

CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -ldflags="-s -w -buildid=" -v ./main

那要是不改构建命令呢 只改 core.go 启动时候的输出 buildvcs=false 了就输出一个custom或者手动注入 有就显示

那要是不改构建命令呢 只改 core.go 启动时候的输出 buildvcs=false 了就输出一个custom或者手动注入 有就显示

我没理解错的话现在就是这样的

现在这样如果没有 buildvcs=false （编译者编译了数据进去） 还是会custom 因为没人去调用vcs数据

那要是不改构建命令呢 只改 core.go 启动时候的输出 buildvcs=false 了就输出一个custom或者手动注入 有就显示

这样好点，之前不知道 Custom 多少年了而且还内嵌了很长一段时间的 VCS
Docker 可以带 VCS，Docker 好像就没有见过要补发的

理解你的意思了，你是想说可以改成没检测到 -buildvcs=false 的话就自动填一下 core.build，我觉得没必要吧就显示个 id 也没啥有效信息，编译者本地的 commit id 我们又不知道代表啥更改，真想看 id 的话可以去读 vcs 信息，毕竟没有 -buildvcs=false 了

并且我也不会去运行别人编译出来的 Xray，不知道里面有啥东西万一有毒呢且违反 MPL-2.0，必须给代码让我自己编译再测试

简单来说就是那个custom可以尽量不显示之类的 显示个hash比显示custom好点

想法是美好的但是真不咋实用，如果让用户自己改代码编译然后贴日志那他也会学去 -buildvcs=false，还得给他说去掉这个以使日志中显示 hash 而不是 custom，他还得说哪个 hash 对应哪个更改，有这功夫不如直接让他说哪份日志对应哪个更改就行了

话说如果 -buildvcs=false 了是不是 debug.ReadBuildInfo() 也读不出 vcs

算了我想了下读 vcs 的代码可以留着就当打个样吧，很智能了可以说是，现有编译流程和编译示例别改就行

刚好也可以起到提醒功能，提醒一下编译有没有 -buildvcs=false，不然如果以后哪天它开始往里面写 email 了那真的难绷

模块带路径好像是C字头语言传下来的 我记得之前反编译游戏的时候可以在模块路径看到作者网名

其它东西比如 flutter 那种又有 C++ 又有 dart 的我都不敢想象带了多少编译环境信息，反正我的 username 几年前就脱敏化处理了

反正对于非 Go 我是不敢自己编译 binary 后传上来的，源码都不太敢传，Xray 官方客户端就 tor codespace 加 copilot 吧

话说如果 -buildvcs=false 了是不是 debug.ReadBuildInfo() 也读不出 vcs

包读不出来的，指定这个就没内嵌 vcs 信息

现有流程是编译时把 Custom 换成指定字符，这样编译出来的 build 变量内容就是指定的内容直接显示在那里

有时候感觉这些信息嵌进去也就调试时有些用处，公开版本的时候还是越少越好，不然被 好事者扒出来什么就不好了

Xray-core 的编译示例正在教大家养成好习惯

理解你的意思了，你是想说可以改成没检测到 -buildvcs=false 的话就自动填一下 core.build，我觉得没必要吧就显示个 id 也没啥有效信息，编译者本地的 commit id 我们又不知道代表啥更改，真想看 id 的话可以去读 vcs 信息，毕竟没有 -buildvcs=false 了

并且我也不会去运行别人编译出来的 Xray，不知道里面有啥东西万一有毒呢且违反 MPL-2.0，必须给代码让我自己编译再测试

请问R佬第三方编译并分发核心违反 MPL-2.0 吗？如果违规的话我会删除我的项目中对核心的分发。我自己写的小玩具还请大佬们轻喷

请问R佬第三方编译并分发核心违反 MPL-2.0 吗？

根据 MPL-2.0 的要求，分发 Xray-fork 的 binary 需要公开源代码且以 MPL-2.0 或 GPL 授权，如果只是 import Xray 则没有该项要求