stephanbuys / docker-compose-types Goto Github PK

Is this designed for docker compose version 2 or 3 or both?
Would be good to document this in the readme.

First off, thank you for creating this crate, it has saved me a lot of work.

I did notice that some properties are missing. I used mailcow's docker-compose.yml as a test because it's rather involved and uses some more obscure options. Here's a list of missing properties that I've found so far:

• services.service.networks.aliases
• services.service.tmpfs
• services.service.volumes.tmpfs
• services.service.sysctls
• services.service.ulimits.nproc
• services.service.security_opt
• networks.network.driver_opts
• networks.network.enable_ipv6
• networks.network.ipam.driver

I'm willing to work on adding these myself. Would you prefer several smaller pull requests or one larger one?

These properties are missing:

• init: bool
• shm_size: byte value
• stdin_open: bool

Hi, docker-compose handles values other than string in environment (as a map), including boolean and number. For example, docker compose run test with the file below prints true and 1234 without any complaints:

version: "3.4"

services:
  test:
    image: busybox
    environment:
      foo: true
      bar: 1234
    command: sh -c 'echo $$foo && echo $$bar'

Tested with Docker version 20.10.17

It was brought to my attention (k9withabone/podlet#31) by one of the users of my podlet project, that the Service struct is missing the userns_mode field. See the linked issue for documentation for the field. Looking at Service's documentation just now I also noticed that the cap_drop field is also missing.

Please, indexmap dependency to version 2

I noticed while writing a little app for my home server setup that there's no explicit support for secrets. They are part of the spec, with top-level and per-service attributes.

It's a giant pain adding them, so I was looking to automate it a bit, and it would great if there was some support for them.

TLDR

If you declare some volumes using the short syntax and some others using the long syntax, the ones using the long syntax will fail parsing. I believe this to be an upstream problem in serde_yaml.

Steps to reproduce

Using Frigate as an example:

version: "3.9"
services:
  frigate:
    image: ghcr.io/blakeblackshear/frigate:stable
    volumes:
      - type: tmpfs
        target: /tmp/cache
      # - type: bind
      #   source: /etc/frigate/config.yml
      #   target: /config/config.yml
      - /etc/frigate/config.yml:/config/config.yml

let yaml = include_str!("frigate.yaml");
let parsed: Compose = serde_yaml::from_str(yaml).unwrap();

Error("services.frigate: data did not match any variant of untagged enum Volumes", line: 4, column: 5)

What I tried

1. Only use short syntax in volumes, one or many items - works.
2. Only use long syntax in volumes, one or many items - works.
3. Mix long and short syntax - fails.

You can verify by commenting and/or uncommenting lines 8-11 in the aforementioned example.

The reason I suspect this is a serde_yaml problem is that the error reminds me of a similar problem I ran into last year: dtolnay/serde-yaml#344. In general serde_yaml seems to be very buggy since the introduction of YAML !tag support in 0.9. I've had to downgrade to 0.8 for a few of my own projects.

Version

serde_yaml: 0.9.27
docker-compose-types: 0.5.1 & 0.6.0

I need this crate derive for my project, and thought I would quickly drop by to write the issue and implement it. I don't see any reason why you would not do this, as it can all be hidden behind a feature flag for the people that don't need it.

All fields on these structures support 'Clone'. It should be straightforward to implement 'Clone' on ComposeFile, SingleService and Compose

Similar to #32, the Service struct is missing the group_add [1] property.

• [1] https://docs.docker.com/compose/compose-file/05-services/#group_add

I'd be happy to see a basic "Parse a file this way" example in the README / top level crate documentation. Maybe something like

let mut def = serde_yaml::from_slice::<YamlValue>(read("./docker-compose.yml")?.as_slice())?;
def.apply_merge()?;
let def = serde_yaml::from_value::<ComposeFile>(def)?;

(There doesn't happen to be a way to handle env expansion that I missed?)

Can you bump serde-yaml to the latest version? Thank you!

https://docs.docker.com/compose/compose-file/#entrypoint

Compose Specification contains 'pull_policy' for Service. It would be good to have it. See https://docs.docker.com/compose/compose-file/05-services/#pull_policy

Hi there,

Thanks for this crate - super useful!

I've just noticed that Volume Labels don't appear to be parsing. Having a look through the test fixtures there's a volumes/volume-label.yml file but i don't think it's getting included in the tests?