3 ms·
Totally agree. I've never used Bazel; it sounds a lot like Nuke. I had a coworker whose job was to maintain the CI. His commit messages would look like this som
by octopoc 5y ago
Totally agree. I've never used Bazel; it sounds a lot like Nuke. I had a coworker whose job was to maintain the CI. His commit messages would look like this sometimes:
> Fix CI issue with blah blah blah
> Hmm that didn't work lets try something from stackoverflow
> Build fix
> Build fix please work
> Please
> I hate my life
> I am tired and hungry, I want to go home
> Stupid yaml
The CTO would call him like a week later to make sure he was okay. This happened often before we switched to Nuke. It rarely happened afterwards. It's awesome being able to debug your CI locally.
- gravypod 5y agoYep, and if you get everything working smoothly enough developers can use the same very polished tooling for their own workflow.
- nly 5y agoThe problem in C++ land (my land) is all your dependencies are probably using different build systems. Do you wan to migrate all your third party libs to Bazel, or just hack up a few lines of CI yaml to call the authors build system? I lean on gitlab yaml quite heavily and it feels quite effortless
- vsgzusnex 5y agoWe vendored all of our third party dependencies into our Bazel build. There were a lot and it was a giant PITA but over a multi-year horizon it was worth it. That doesn't mean it's the right choice for every business but it paid off for us.
- nly 5y agoVendoring all your third party dependencies is fine, but you still have to build them. Personally I use the native build system that upstream uses for most of them, and just hack in my compiler flags/options where necessary. Then I use CI triggers to rebuild my projects when the dependencies are rebuilt.