docker_compose_v2_pull: add ignore_buildable option (and/or extra_args)

[mjbogusz]

SUMMARY

As the title says - it'd be great if the module had an equivalent of --ignore-buildable flag.

This would allow for a more smallest-step-possible approach, which I'm trying to achieve (pull, build, up all in separate steps).

ISSUE TYPE

• Feature Idea

COMPONENT NAME

docker_compose_v2_pull module

ADDITIONAL INFORMATION

I believe a ignore_buildable: bool flag could be added, defaulting to False, which if set to True would add the --ignore-buildable flag to the docker compose call.

Alternatively (or additionally, as it's not exclusive) an extra_args flag would allow for better flexibility at the cost of slightly higher fragility of users' setups if used.

Example playbook (partial) showing what I'd like to achieve:

tasks: 
  - name: Pull external docker images
    community.docker.docker_compose_v2_pull:
      project_src: /path/to/project
      # This is what I'd love here
      ignore_buildable: true
      # Alternatively, this would be great too
      extra_args: '--ignore-buildable'
      
  - name: Build internal docker images
    community.docker.docker_compose_v2:
      project_src: /path/to/project
      state: absent
      build: always

  - name: Start the thing
    community.docker.docker_compose_v2:
      project_src: /path/to/project
      state: present
      wait: true

[felixfontein]

Options like extra_args are dangerous, I won't add anything like that. But ignore_buildable sounds good to me!

[felixfontein]

#942 adds this option (and two more, while being at it...).

[mjbogusz]

Nice, thanks!

That's what I thought as well about extra_args - it sounds great until everyone abuses it and then it breaks ;)

---

Also, for anyone trying to achieve what I've described in the first post: unfortunately the build part of my example playbook is not 100% correct either, as if I understand correctly it tries to do something like docker compose down --build which makes no sense.

For now I've worked around it by just throwing in a ansible.builtin.command, but maybe a build_only flag would be a way to go - I'll try digging more into it and potentially I'll post another feature request.

For a brief moment I've thought about a docker_compose_v2_build module but that would imply a need for a dozen others ;)

[felixfontein]

Also, for anyone trying to achieve what I've described in the first post: unfortunately the build part of my example playbook is not 100% correct either, as if I understand correctly it tries to do something like docker compose down --build which makes no sense.

It makes sense only if you're sure that the service wasn't running :)

For now I've worked around it by just throwing in a ansible.builtin.command, but maybe a build_only flag would be a way to go - I'll try digging more into it and potentially I'll post another feature request.

For a brief moment I've thought about a docker_compose_v2_build module but that would imply a need for a dozen others ;)

Actually a docker_compose_v2_build module would be the proper solution. (We actually had an issue for potentially that #750, but in that case it turned out that the person requesting it mainly needed the build=true option for docker_compose_v2.)

Also there's no need for a dozen others, since most subcommands of docker compose either make no sense or should be part of docker_compose_v2:

attach: makes no sense since it is continuously displaying data
events: makes no sense since it is continuously displaying data
scale: makes no sense, since scaling can already be done with docker_compose_v2
stats: makes no sense since it is continuously displaying data
watch: makes no sense since it is continuously displaying data

build: makes sense as its own module docker_compose_v2_build
cp: makes sense as its own module, or two (copy into/out of container?)
exec: makes sense as its own module docker_compose_v2_exec
push: makes sense as its own module docker_compose_v2_push
run: makes sense as its own module docker_compose_v2_run
wait: might make sense as its own module

config: not sure, could be its own _info module?
images: used by docker_compose_v2, could be used by _info module
logs: could make sense as its own _info module
ls: not sure, could be its own _info module?
port: could maybe be used in an _info module
ps: used by docker_compose_v2, could be used by _info module
top: could be used in an _info module
version: used by all modules internally, could be used in an _info module

create: could be a state of docker_compose_v2
kill: could be a state / option of docker_compose_v2
pause: could be a state of docker_compose_v2
unpause: could be a state of docker_compose_v2
start: could be a state of docker_compose_v2

down: is a state of docker_compose_v2
restart: is a state of docker_compose_v2
rm: is a state of docker_compose_v2
stop: is a state of docker_compose_v2
up: is a state of docker_compose_v2
pull: used by docker_compose_v2_pull

I'm generally not implementing anything here without anyone asking for it (and presenting some use-case that makes sense).

Having a module for docker compose build does make sense I guess; while you can also simply use ansible.builtin.command, checking whether something actually changed is less trivial (and can easily be done with the code we already have).