stephanbuys / docker-compose-types Goto Github PK

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?)

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

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

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.

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

It was brought to my attention (containers/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.

These properties are missing:

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

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 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.

Please, indexmap dependency to version 2

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?

  some-other-daemon:
    extends: some-daemon
    image: docker.io/good-repo:latest

This is a valid notation for extends, and you can even interpret https://docs.docker.com/compose/multiple-compose-files/extends/#extending-services-within-the-same-file that it is the preferred notation unless you are extending from another file.

But using that notation fails, with docker-compose-types expecting a map, not a string.

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

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

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

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?

It would be good to update derive_builder to 0.20.0.

Probably, you'll need to bump a minor version as 0.20.0 introduced one breaking change. I'm not sure if it affects 'docker-compose-types'. See here

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