3 ms·
If I'm understanding you correctly that's using bazel to _build_ a deployment script/deployment tool (injecting the actual deployment artefacts as build depende
by azornathogron 5y ago
If 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.
- jvolkman 5y ago`app_prod.apply` is just an executable target that can do the non-hermetic stuff. The hermetic building of rendered yaml files, docker images containing built app artifacts, etc. happens through normal Bazel actions.