3 ms·
Not real informative but it did bring up bazel which I went and looked at: https://bazel.build/docs https://bazel.build/docs Wondering what the experiences of
by kerblang 5y ago
Not real informative but it did bring up bazel which I went and looked at: https://bazel.build/docs https://bazel.build/docs
Wondering what the experiences of others are with this thing. It claims to be anti-"task-based" which strikes me as anti-flexible, although it does appear to have a custom programming language... eh... Suppose I wanted to add ssh/scp, how would I do that?
- jvolkman 5y agoAdd ssh/scp to do what?
- kerblang 5y agoLike, say, a deploy. For example's sake.
- jvolkman 5y agoSure. You can add a *_binary target (say, a shell script or a python script) that takes as input some build output and scps it somewhere.
- shawabawa3 5y agoYou wouldn't Wrong tool for the job You'd have bazel build a deployer tool which would run ssh/whatever to do the deploys
- pharmakom 5y agoYou can perform bazel run to execute a build artefact. This executable could run a deployment, SSH somewhere, etc. The advantage of this is that Bazel will ensure the artefacts the executable needs are built before execution.
- azornathogron 5y agoBazel isn't a general purpose a automation tool or a deployment tool, so, you wouldn't use Bazel for this. Your deployment script would run Bazel to build your binary/container image/whatever. That is, building might be part of the deployment process, but deploying is not part of the build process.
- jvolkman 5y agoI'm not sure it's so black and white. We have bazel targets that invoke the Serverless framework (for deploying to lambda), or invoke kubectl (rules_k8s), and we `bazel run` these targets in our GitHub workflows. Through dependency resolution, running the deploy targets will rebuild artifacts as necessary (a lambda archive, a docker image, rendered kubernetes yaml) as needed.
- azornathogron 5y agoIf I'm understanding you correctly that's using bazel to _build_ a deployment script/deployment tool (injecting the actual deployment artefacts as build dependencies) and then running the script? I think that's compatible logically with what I said, but I agree that setup does blur the boundaries a bit.
- jvolkman 5y agoIt's one command. e.g.: > bazel run //k8s:app_prod.apply this command will: 1. build the app, as needed (java, python, go, or some mixture) 2. build and push docker images, as needed. 3. render kubernetes manifests, replacing image name placeholders with something that exactly matches what's been pushed. 4. apply the kubernetes manifests to a the cluster. Of course we still use an automation system (Github workflows), and it does a few more things such as actually installing bazel, setting up some credentials, etc. But yeah - the lines are blurred.
- azornathogron 5y agoWell now I'm curious how the push-docker-image step is implemented...? :-) `bazel run` just builds the specified target (a normal hermetic build) and then executes what it just built (not hermetic). But if you're actually pushing images to somewhere as part of the build itself (not pushing as part of whatever the app_prod.apply tool does) then that sounds like a non-hermetic/non-reproducible build step, which makes me think there's something happening that I don't understand. Sounds interesting.
- nisa 5y agobazel is a very powerful tool due to it's design builds are fully cacheable und you can bring your own toolchain - so it's good for having reproducible builds without any system dependencies - here is an complete example: https://github.com/drakery3d/fullbazel https://github.com/drakery3d/fullbazel - it's flexible and powerful but also complicated and it's probably difficult to convince your team/org to adopt it.