Best Practices for running Bazel in Jenkins environment?
Steve Munday
Hi all, I have a question that was originally posted on Github was it was suggested I try here instead. Thanks in advance to anyone who has some insight.
Description of the question:
We have a mono-repo environment with a number of projects, mostly C++, iOS and Android. For any given Pull Request to our repo, we would like to run 4 builds: 2 iOS apps and 2 Android apps, with Bazel underpinnings, but not all on Bazel (yet).
We are currently doing this using a "vendored" approach - the Bazel binary was committed into the repo and build scripts modify the environment to use this binary. This has two major advantages - upgrading Bazel is easy for everyone (just a commit), and each job workspace can run Bazel commands in parallel (using their own binary).
I'm concerned that there are troubling tradeoffs here. It seems that we don't really benefit from a lot of the advantages of Bazel - a lot of our build jobs are rebuilding things that were not changed. I think the daemon process is constantly being whacked by other copies of itself, and the disk caches in /private/var/tmp/... can get huge and numerous. Our builds are slower than they should be.
Now to my real question to you, knowledgeable Bazel team: Is this "vendored" approach workable or are we losing some of the benefits of Bazel by doing this? Are we using this tool incorrectly?
If possible, provide a minimal example to reproduce the problem:
- Build an iOS app.
- Create a repo with the Bazel binary at
/tools/vendor/bazel. - Execute a build on Jenkins using this binary instead of the one installed on the machine.
- Execute 3 more on the same machine in parallel.
Environment info
Operating System:
Jenkins Master: Ubuntu Xenial
Jenkins Slaves: MacOS Sierra 10.12.5Bazel version:
0.4.5
Have you found anything relevant by searching the web?
We use a variation on this script: ci.sh to identify what needs to be rebuilt, but this only works if all of your targets are under Bazel. In our case, they are not yet - so a certain class of changes will bypass the build process.
