Setting a service image, and any compose update, on an existing deployment fails validation when the compose uses a relative env_file such as ./.env, returning invalid compose: env file ./.env not found: stat ./.env: no such file or directory, even though the file exists in the deployment directory. Bringing the deployment up works because that path runs compose from the deployment directory, while validation hardcodes the working directory to . (the agent's own directory), so the relative path resolves against the wrong place. Only env_file triggers it: the loader reads it at parse time, while bind-mount volumes referencing the same ./.env are never checked, so the bug stayed latent until a service used env_file.

validateComposeWithComposeGo sets WorkingDir: ".", and validateComposeContent discards the deployment name it receives, so the update and compose-mount handlers pass the name but validation never learns which directory to resolve against.

Checklist

• Thread the deployment name through compose validation to the compose-go loader
• Validate with the working directory set to the deployment directory for existing-deployment paths (update, compose mount)
• Keep the create path working when the directory does not yet exist
• Add a regression test for a compose whose relative env_file exists in the deployment directory

Related

• Part of group(enhancements): Albacore #158