More Documentation?

[afgarcia86]

I am really interested in using this as it seems like it will help me solve the problem we have with all our bazel micro-services. I was having trouble getting the example app to run, I feel like I am missing something in the documentation.

[gravypod]

Hey! I no longer work at caper so I'm unable to externalize the internal documentation I wrote. Essentially you do the following:

1. Create a bazel-composel.yml file that follows the docker-compose config file format except instead of specifying images using docker hub image tags you use their bazel target label (//a:b)
2. (Optional) Create a docker-compose.yml like you normally would for services you run daily (ex: mysql, etc). Stuff you don't build that you just always need to start up to have your containers run. You can optionally put these in bazel-compose.yml but I merge the two files because at Caper we did a gradual migration and wanted to support both docker-compose AND bazel_compose at the same time with the same set of services.
3. Install iblaze
4. Install bazel_compose. This is a tricky one. At Caper we used a monorepo and so I never packaged this tool up into a single binary for easy deployment to people externally from our monorepo. That's also why there's the really strange bazel run ... command in our README.md. So:
   • A: copy all of this source into your source tree
   • B: find some way to build the py_binary and add it into your PATH.

That's the short and sweet of it. There are also some CLI arguments that are incorrect here I think so I'll give a brief explanation of what's what:

    parser = ArgumentParser()
    parser.add_argument("cwd", help="Current working directory for all subcommands", default=".")
    parser.add_argument("--everything", help="Current working directory for all subcommands", default=True, type=bool)
    parser.add_argument("--follow", help="Tail the logs of a specific subset of containers", nargs='*')

• cwd: Where your source tree lives. This had to be passed in via ${PWD} because bazel runs your commands in a sandbox so it would actually see your source tree. If you use something like bzl you can do bzl exec //caper/bazel_compose
• --everything: This runs a single docker-compose up before running any other command. This is useful becase bazel_compose only runs docker-compose up <service_name> when it starts bazel containers. If you don't want to specify this tag you just need to specify depends_on.
• --follow: You can specify --follow foobar and the bazel_compose command will only print lines from that specific container. It defaults to logging all lines from all containers to stdout. This is annoying when you have DBs running (mysql, mongo, etc) because those get very spammy and are usually not what you care about seeing logs from.

I'm also available on bazel's slack. Feel free to ping me there.

[gravypod]

@afgarcia86 I've made a fork and fixed some of the things discussed above. I've:

1. included a usage example
2. pre-built a binary
3. added some install instructions

It's available here: https://github.com/gravypod/bazel_compose

[afgarcia86]

Awesome, I am trying to install your binary but it seems to return Not Found 🤔

[gravypod]

@afgarcia86 , hmm it doesn't seem to be public. That's unfortunate. I don't have much experience with GitHub. You can do the following to get the binary though:

1. clone the repo
2. bazel build //caper/bazel_compose:bazel_compose.par
3. sudo cp bazel-bin/caper/bazel_compose/bazel_compose.par /usr/local/bin/bazel-compose

That should get you started for now. I'll have to mess around with it when I have more time. See if I can setup GitHub actions or something.

[afgarcia86]

Sweet that works! looking forward to playing around with this thanks for the help.

You may want to update the docs in your fork. bazel_compose.par" -o /usr/local/bin/docker-compose <- when I ran that I blew away my docker-compose

[gravypod]

Good catch! Sorry about that! Fix applied. Let me know how you like the tool or if you run into any issues.