Question: Is it possible to configure labels for all services?

[camjackson]

All of my containers will have the same values for these config items:

• io.fdy.cage.srcdir
• io.fdy.cage.shell
• io.fdy.cage.test

Is there somewhere I can configure these so that it will apply to all services?

[emk]

That's an excellent question! And no, I don't think we ever added support for that.

Part of the issue here is that we try to add as few extensions to docker-compose.yml as possible, which makes it hard to do things like this. We were thinking of implementing something like extends for these cases, but then Docker removed support for that in newer versions of the format.

We have a similar problem with .metadata.yml files.

At some point, we might need to bite the bullet and add non-compatible extensions to docker-compose.yml. We've been trying to avoid this, but there may be no better choice. :-(

[camjackson]

Thanks for the quick response!

If you don't want to pollute the pod files with non-docker-compose stuff, another solution might be to put it in /config/project.yml? Or maybe a file like /config/defaults.yml? And then allow a structure like:

defaults:
  srcdir: /app
  shell: bash
  test: yarn test

[emk]

Yeah, it would be really easy to implement something like this, but the hard part is doing it in a way that doesn't feel gross and ad hoc. I think that we really need to decide how much we're going to rely on docker-compose.yml, and whether we're willing to "officially" extend that format in a systematic way.

I wish I had a quicker answer, but I'd rather get this right. All my instincts say that it would be far too easy to add cruft here, and we probably want a more general solution.

[camjackson]

That sounds very wise. There are enough developer tools already where features feel bolted on, rather than thoroughly designed.

It feels like there a few different directions. If you keep it the same as docker-compose.yml, then people can always paste in their ports/environment/working_dir/command config from an existing file and know it will work without having to go and look up the Cage documentation. Which is awesome. But then you'll probably often feel limited with things like this issue.

You could say it's docker-compose.yml + some of your own extensions, but then it goes from "oh it's just docker compose" to "it's a very leaky abstraction over docker compose".

The more extreme option would be to design a totally custom format, but that's probably a lot of work to design+implement+document, and raises the barrier to learning the tool.

Tough call! 🤔