Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[go] migrate from dep to go mod (chef#1837)
Go introduced module mode in v1.11 and it became the default in v1.13. This change replaces `dep` with `go mod` using a vendor directory. * You no longer need to have the Chef Automate git repository inside of a `GOPATH`. Instead, all `go` utilities will recognize that they are in module mode and will handle dependency loading for you. You're now free to keep the Chef Automate source code in any directory you wish. You can even unset `GOPATH`. 🎉 * The `go` command supports using a module vendor directory but it has to be explicitly enabled with the `-mod=vendor` go flag. If you prefer not specifying it each time you can set the `GOFLAGS=-mod=vendor` environment variable. We have done this in the studio so all go commands should utilize the vendored dependencies, but if you run go commands outside of the studio you'll need to specify the flag or set the environment variable to utilize the vendored dependencies. If you forget, commands should still execute but they will download the modules into your go installations modules directory instead of using the vendored packages. * Inside the studio the `GOBIN` has been set to `/src/bin`, which means `/bin` relative to the Chef Automate source code directory outside of the studio. This has the effect that installed binaries that are compiled in the studio are also available outside of the studio. This provides the benefit that go development tools that have compiled inside the studio don't have to be re-compiled each time you start a new studio container. It also means that protobuf compilers and extensions are also cached, therefore you might have to manually remove them if changes are made. If you notice strange behavior when compiling protobufs, remove the compiled binaries in `/bin` and try again. * `enter_go_workspace`, `setup_go_workspace`, and other various studio functions that are required when working with go in `GOPATH` mode are no longer required. I tried to update every studio function but it's likely that something slipped though the cracks. If you notice that your studio function is behaving incorrectly please accept my apologies now. * Some, but not all, of the protobuf compilers and extensions that we use in Chef Automate are not compatible in module mode. All of the `grpc.sh` protobuf scripts have been updated to utilize relative source path outputs where supported, otherwise measures have been put in place to compile them and move them into the correct directory afterwards. * Vendoring is no longer done with `dep`. Adding a new dependency to Chef Automate is now as easy as importing the package into your go application and running `make revendor` from the root of the Chef Automate source code repo or in the studio. If you require go packages for development that are not included in the Chef Automate repository, add them to the `vendor.go` as ignored dependencies and revendor. * Many packages were updated as part of this migration. Everything has been recompiled with the new vendor directory and the single known regression has been fixed. If a dep change has caused you problems we can work to pin it. * We previously relied on 3 different layers of scaffolding: `core/scaffolding-go`, `chef/scaffolding-go` and `chef/automate-scaffolding-go`. That's two layers of scaffolding too many. Because we're now in module mode our scaffolding that handled much of the `GOPATH` wonkiness is no longer required, thus all packages that require go have been migrated to `chef/automate-scaffolding-go`, which has been updated for the go mod with vendor directory workflow. If you add a new go component you should use `chef/automate-scaffolding-go`. If you need to opt out of the platform scaffolding for a go package you can set the new `scaffolding_no_platform` variable to true in the plan. * Default version linker flags are now set in the scaffolding. You don't need to manually set them in your plans. * Platform TLS CA and certs are handled by the scaffolding, you don't need to specify them in your plans. Sorry, we did our best to make this transition as seamless as possible. Reach out to #a2-deployment and we'll do our best to help out. [go] replace dep with go mod vendoring [automate-scaffolding-go] add go mod support to automate-scaffolding-go [automate-scaffolding-go] remove dependency on core and chef go scaffolding [hab-plans] migrate all plans to automate-scaffolding-go [hab-plans] remove unused platform TLS config [hab-plans] use scaffolding version linker flags everywhere [gprc] update all grpc.sh scripts to use relative source paths where possible [studio] remove GOPATH requirements from all studio functions [lib/cereal] fix a regression caused by `lib/pq` library breaking changes [bldr] refactor bldr generator tool for module mode [repo-health] update repo health checks for module mode Signed-off-by: Ryan Cragun <[email protected]>
- Loading branch information