4 ms·

Bazel 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

Bazel 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 ago
I'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 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 ago
    It'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 ago
      Well 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.

jvolkman 5y ago

I'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 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 ago
  It'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 ago
    Well 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.