[Upstream #98] job-exec with swarm container

[CybotTM]

Original Issue

mcuadros#98

Summary

job-exec not working with Swarm containers.

Decision Needed

• Investigate
• Won't implement (reason: ___)

[CybotTM]

Analysis: Feature Request (Not a Bug)

This is a feature request for supporting dynamic container resolution in job-exec.

Current Behavior

The Container field in job-exec expects an exact container name or ID:

// core/execjob.go line 16
Container string \`hash:"true"\`

// Line 51-54: Direct use without pattern matching
exitCode, err := j.Provider.RunExec(
    context.Background(),
    j.Container,  // Used directly
    config,
    ...
)

User Request

Support for Swarm containers where names are dynamic (e.g., mongo_mongo1.1.f0dmbbmxwza22tzqfhnopzt3f):

• Container name pattern matching (like name=mongo*)
• Service-based container discovery
• Filter-based container selection

Proposed Solution

Add a new container-filter option that resolves to container ID at execution time:

[job-exec "mongodump"]
schedule = @daily
container-filter = name=mongo_mongo*
command = mongodump

Implementation would:

1. At job execution time, list containers matching filter
2. If exactly one match, use that container
3. If multiple matches, either error or use first (configurable)
4. If no matches, fail with clear error

Workarounds

1. job-service-run: Create a new service instead of exec into existing container
2. External wrapper: Script that resolves container and calls ofelia
3. Label-based discovery: Use ofelia.enabled=true label on the target container

Labels

Re-labeling as Feature Request since this is not a bug but a missing capability.