kevinveenbirkenbach 673ccc5f40 fix(plugins/container_service): swarm uses stack_servicekey, not stack_name ...

`docker stack deploy` names services `<stack>_<compose-yaml-key>` and
silently ignores the compose `name:` field (that field maps to the
compose-only `container_name`). The lookup was returning
`<stack>_<services.<key>.name>` instead, which only happened to be
correct when the YAML key and the `name:` field matched.

The matomo bootstrap service is the failure case: services.bootstrap.name
is `matomo-bootstrap` but the YAML key (and therefore the swarm
service name) is `bootstrap`. The lookup returned
`matomo_matomo-bootstrap`, the bootstrap-wait task polled an absent
service, and the wait timed out after 7 empty retries -- root cause
of the act-39 swarm bootstrap stall.

- plugins/lookup/container_service.py: swarm branch returns
  `<stack>_<service_key>`; compose branch unchanged.
- tests/unit/plugins/lookup/test_container_service.py: flip the two
  swarm assertions to the corrected expectations and rename
  `test_swarm_mode_uses_resolved_service_name` ->
  `test_swarm_mode_ignores_services_name_field` so the contract is
  visible from the test name.

2026-06-14 19:08:45 +02:00

..

action

refactor(stack_host_template): generalise IS_STACK_HOST template wrapper across the codebase

2026-06-06 15:45:38 +02:00

filter

fix(env-templates): make dotenv_quote swarm-aware (compose strips, swarm preserves)

2026-06-14 19:08:45 +02:00

lookup

fix(plugins/container_service): swarm uses stack_servicekey, not stack_name

2026-06-14 19:08:45 +02:00

__init__.py

…