Dnia 2017-01-06, o godz. 14:19:28 Jacek Furmankiewicz <jace...@gmail.com> napisał(a):
> What happens when you have multiple projects, all with different versions > of the same library ( some projects are newer, some older, some more > maintained than others, etc). > > Would you need a different GOPATH per project? Jacek, take a look at gb [1] and vendoring [2]. Though for your needs there is a much simpler solution: This is Go. It produces a single binary for deployment. For SOC2 compliance you will use (you already use) a builder. This is a single place where you exercise your control over what can and what can not go into the executable. Make your lawyers responsible for single 'official' gopath @builder. Then tell your devs they may not use go get by themselves, everything they need they should pull from the GOPATH@builder. If they won't abide to this, their source simply will not compile @builder on commit hook; hence it will not get into your controlled repo, ever. Voilà. For the tagged production versions I would suggest to: - make separate "version" branch - copy used libs to the vendor/ [2] - optionally copy whole environment for reproductible build All above may happen automagically on post-receive hook for a tag. This way you will get CI on a single (dev/prod) repo and fully reproductible [3] builds. All with official tools only and under your tight control. [1] https://getgb.io/ [2] https://blog.gopheracademy.com/advent-2015/vendor-folder/ [3] as far as go compiler allows for https://github.com/golang/go/issues/16860 Hpoe this helps, -- Wojciech S. Czarnecki ^oo^ OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
