The entire bazel playlist is really helpful. Using bazel appears to be daunting task at first, but you have broken it down into multiple videos nicely and its easy to follow. Thank you
Hi @supervacuum, the benefits of bazel aren't as clear for small projects. In large enterprises with 100s different microservices, a bazel monorepo can be very effective.
@@KrisFoster1 I see your point - we have used a different approach, each microservice has its own repository and we use GitLab templates to manage all the common aspects of the build. Pros and cons, like any other technology. Thanks for making the video, very informative!
I think gazelle is supposed to create the BUILD.bazel files in each project. They were built manually in this video which may be what you want when building from scratch. th-cam.com/video/mXLrk0ipwz4/w-d-xo.html Shows using gazelle if adding Bazel to an existing project. You can probably use gazelle for either type.
@@garrettsaxton That's how I understand it too: unlike other languages which Bazel supports, Go knows quite well how to get the dependencies, even remote, when using the modules mechanisms, so these BUILD.bazel files and the go_repository section in WORKSPACE.bazel look like they can completely be autogenerated from code, and that's what the Gazelle intro describes as being its purpose too. A middleground is using vendoring, which obviates the need to declare all those go_repository entries at the top, and allows referencing them straight from the monorepo top-level vendor directory (with a top-level go.mod).
I dont know is the rule is different or what happens, but I can not achieve to execute the build with successful finished. The problem is on goilla/mux inside of BUILD.bazel of the go_web project.
Thanks a lot kris for this series. Super helpful !!
The entire bazel playlist is really helpful. Using bazel appears to be daunting task at first, but you have broken it down into multiple videos nicely and its easy to follow. Thank you
Thank you very much for the feedback, really glad that you found the videos useful!
Super helpful content thank you :)
how does this work using Go modules? Do you still have to bring in all dependencies manually in bazel's BUILD file?
I struggle to see the benefit of using Bazel, seems overly complicated and surely a Makefile would have yielded the same result?
Hi @supervacuum, the benefits of bazel aren't as clear for small projects. In large enterprises with 100s different microservices, a bazel monorepo can be very effective.
@@KrisFoster1 I see your point - we have used a different approach, each microservice has its own repository and we use GitLab templates to manage all the common aspects of the build. Pros and cons, like any other technology. Thanks for making the video, very informative!
have you tried to run bazel with gomock before?
What exactly did Gazelle do for you here?
I think gazelle is supposed to create the BUILD.bazel files in each project. They were built manually in this video which may be what you want when building from scratch. th-cam.com/video/mXLrk0ipwz4/w-d-xo.html Shows using gazelle if adding Bazel to an existing project. You can probably use gazelle for either type.
@@garrettsaxton That's how I understand it too: unlike other languages which Bazel supports, Go knows quite well how to get the dependencies, even remote, when using the modules mechanisms, so these BUILD.bazel files and the go_repository section in WORKSPACE.bazel look like they can completely be autogenerated from code, and that's what the Gazelle intro describes as being its purpose too. A middleground is using vendoring, which obviates the need to declare all those go_repository entries at the top, and allows referencing them straight from the monorepo top-level vendor directory (with a top-level go.mod).
I dont know is the rule is different or what happens, but I can not achieve to execute the build with successful finished. The problem is on goilla/mux inside of BUILD.bazel of the go_web project.