在 concourse-ci 任务中使用 go 有哪些好的模式。例如,我是否应该在本地构建具有所有依赖项的文件并将交叉编译的二进制文件签入到 repo?我应该在运行任务之前建立大厅吗?
人们在这里所做的事情的例子会很棒。管道/任务的公共存储库更好。
在我看来,目前有 3 个选项用于处理 go build:
所有选项都有优点和缺点。第一个选项目前是我最喜欢的,因为处理依赖项的责任取决于项目维护者,并且有一种非常清晰的方法可以查看正在使用的依赖项的哪些版本/修订版 - 即只需检查供应商工具配置 - 但确实如此强制您在项目的存储库中拥有所有依赖项代码。
第二个选项遵循始终跟踪 master 的 go“哲学”,但它可能会导致构建速度变慢(concourse 需要定期检查每个资源)并且可能由于依赖关系的变化而导致突然损坏。
第三个选项允许您隐式修复 docker 映像中依赖项的修订,在这方面它类似于第一个,但是它需要维护 docker 映像(不一定意味着每个项目 1 个,但可能意味着多个取决于使用此选项的项目数量以及它们之间是否存在冲突的依赖版本)