add Dockerfile.build-and-run to realize multi-stage build;fix @testin…

[ColorfulDick]

…g-library/[email protected] has unmet peer dependency @testing-library/dom@>=5

搞一个多阶段构建的dockerfile，包含了node和golang的依赖，自动构建最小化镜像，这样用户可以不用自己搭建环境，并用上最新的代码；经过测试在开启科学上网的情况下，构建成功率百分之百

[kira1928]

这个是计划给不懂代码的用户用的吗？
如果是方便开发人员，我觉得配置一个 devcontainer 文件会极大降低其他人参与这个项目的开发的门槛。
如果是为了不懂代码的人可以用上还没有发release的最新代码，我个人还是倾向于不要给非程序员用户这么高难度的选项。
可能会有很多人发 issue 问为什么自己的 docker 启动不起来之类的问题。
以前有段时间收到很多 docker 相关问题我就挺绝望的 orz

[ColorfulDick]

这个是计划给不懂代码的用户用的吗？ 如果是方便开发人员，我觉得配置一个 devcontainer 文件会极大降低其他人参与这个项目的开发的门槛。 如果是为了不懂代码的人可以用上还没有发release的最新代码，我个人还是倾向于不要给非程序员用户这么高难度的选项。 可能会有很多人发 issue 问为什么自己的 docker 启动不起来之类的问题。 以前有段时间收到很多 docker 相关问题我就挺绝望的 orz

并没那么复杂的意图，只是项目之前那个Dockerfile只支持基于已经编译好的二进制程序进行构建，而我commit的这份Dockerfile.build-and-run支持完全通过源码(无论arm还是x86)进行docker镜像构建，包括了前端打包以及golang二进制编译的部分，无论对开发者还是普通用户都是巨大的便利性

[kira1928]

这个项目最初也是用的本地编译binary包进本地docker image，但从某个时期开始，原作者修改了docker包含可执行文件的方式到了现在这样。我猜这是为了更好地统计用户数量（github release有下载计数）。
为了普通用户的统一使用体验，我还是认为不要把编译未成熟的代码的能力开放给普通用户。而针对开发者，我们应该使用devcontainer（也是docker，你的代码可能大部分可以复用）

我们等一下 @hr3lxphr6j 的意见吧

[hr3lxphr6j]

这个项目最初也是用的本地编译binary包进本地docker image，但从某个时期开始，原作者修改了docker包含可执行文件的方式到了现在这样。我猜这是为了更好地统计用户数量（github release有下载计数）。 为了普通用户的统一使用体验，我还是认为不要把编译未成熟的代码的能力开放给普通用户。而针对开发者，我们应该使用devcontainer（也是docker，你的代码可能大部分可以复用）

我们等一下 @hr3lxphr6j 的意见吧

当初把编译扔到docker build外的主要目标是减少CI的执行时间，避免超时。如果放在docker build里，go mod download、node modules下载和node build的时间就是O(n)的（arch数），也没法利用go build产生的cache，导致执行时间会非常长，我记得会到小时级别。

所以我想法是：

• 对于CI还是保留现状，docker build时直接下载releases，节省时间
• 对于用户在本地编译的需求则可以使用这个PR的方法，在docker中构建

PR方面的话有几个问题哈：

• test.sh的用途是？
• 可以让改造makefile中dev目标，使用这里逻辑，如果觉得编写makefile有困难的话可以先merge之后我来做。

[kira1928]

如果是方便开发人员，我觉得配置一个 devcontainer 文件会极大降低其他人参与这个项目的开发的门槛。
如果是为了不懂代码的人可以用上还没有发release的最新代码，我个人还是倾向于不要给非程序员用户这么高难度的选项。
可能会有很多人发 issue 问为什么自己的 docker 启动不起来之类的问题。
以前有段时间收到很多 docker 相关问题我就挺绝望的 orz

这个观点 @hr3lxphr6j 怎么看？

[hr3lxphr6j]

如果是方便开发人员，我觉得配置一个 devcontainer 文件会极大降低其他人参与这个项目的开发的门槛。
如果是为了不懂代码的人可以用上还没有发release的最新代码，我个人还是倾向于不要给非程序员用户这么高难度的选项。
可能会有很多人发 issue 问为什么自己的 docker 启动不起来之类的问题。
以前有段时间收到很多 docker 相关问题我就挺绝望的 orz

这个观点 @hr3lxphr6j 怎么看？

emmm，对于大部分不懂代码的人，安装docker和搞一个能运行make dev的环境本身就是个坎，这本身就是个筛选过程。
对于想尝鲜的普通用户，之后可以考虑master分支每次有变更就构建一个使用mastertag的docker image（master分支保证能过CI）。
之后开发新功能和修bug都fork一个分支，做好了再提PR合到master。

[ColorfulDick]

这个项目最初也是用的本地编译binary包进本地docker image，但从某个时期开始，原作者修改了docker包含可执行文件的方式到了现在这样。我猜这是为了更好地统计用户数量（github release有下载计数）。 为了普通用户的统一使用体验，我还是认为不要把编译未成熟的代码的能力开放给普通用户。而针对开发者，我们应该使用devcontainer（也是docker，你的代码可能大部分可以复用）
我们等一下 @hr3lxphr6j 的意见吧

当初把编译扔到docker build外的主要目标是减少CI的执行时间，避免超时。如果放在docker build里，go mod download、node modules下载和node build的时间就是O(n)的（arch数），也没法利用go build产生的cache，导致执行时间会非常长，我记得会到小时级别。

所以我想法是：

• 对于CI还是保留现状，docker build时直接下载releases，节省时间
• 对于用户在本地编译的需求则可以使用这个PR的方法，在docker中构建

PR方面的话有几个问题哈：

• test.sh的用途是？
• 可以让改造makefile中dev目标，使用这里逻辑，如果觉得编写makefile有困难的话可以先merge之后我来做。

抱歉，是我的失误，我已经revert并删除了test.sh；我并不熟悉makefile,能力范围内仅能提供dockerfile

[hr3lxphr6j]

LGTM

[kira1928]

这会不会对不在国内的开发者有点不方便。。

[kira1928]

不知道 docker 构建时能否从外部设置代理，或者默认在OS的代理设置下访问网络。

比起硬编码代理到dockerfile里，让用户在外部翻墙也许通用性更好一些。

[kira1928]

或者留一个可以从构建时的命令行获取代理信息的变量？

[ColorfulDick]

不知道 docker 构建时能否从外部设置代理，或者默认在OS的代理设置下访问网络。

比起硬编码代理到dockerfile里，让用户在外部翻墙也许通用性更好一些。

我先移除了设置golang国内源这行吧，确实有些多余，感觉国内的开发者但凡用到docker，应该都具备科学上网的能力

[kira1928]

我可能周末有时间的时候会在本地测试一下这个dockerfile，没问题就merge了。

@hr3lxphr6j 如果有空测试的话，你直接merge就可以。