[TDnorthgarden]

Problem

createLayers and processExtends return processFile errors unwrapped.
A failure in any of the project's compose files — the ones pulled in
through extends included — reaches the user with no hint of which file
to fix:

$ docker compose publish
service "web": env_file is in flow style, which cannot be rewritten while preserving formatting

With several compose files in play, the user has to open each one to find
the offender.

Fix

Wrap the two processFile call sites (createLayers, processExtends)
with the file name:

failed to process compose file ./override.yaml: service "web": env_file is in flow style, ...

Suggested in the #14387 review.

[ndeloof]

Thanks @TDnorthgarden, the change itself is correct and consistent with the surrounding error messages (both processFile callers are covered, %w keeps errors.Is/errors.As, and processExtends doesn't double-wrap).

That said, this is the follow-up suggested in the review of #14387, and since #14387 is still under review there is little point in landing it separately. Could you fold this commit into #14387 and close this PR?

Two reasons for doing it there:

• The motivating case (service "web": env_file is in flow style…) only exists with fix(transform): don't panic on flow-style compose files in publish rewrites #14387, so the example in this description can't be reproduced on main.
• The test here is weaker than it looks: the underlying os.ReadFile error already contains the path, so ErrorContains(err, "missing.yaml") still passes if the file name is dropped from the wrapper (I checked by removing the %s). The flow-style error from fix(transform): don't panic on flow-style compose files in publish rewrites #14387 doesn't name any file, so a test built on it will really exercise the wrapper. Please assert the exact prefix, e.g. failed to process compose file <path>: , rather than only the file name.

Two small things while you are at it: the description uses ./override.yaml whereas project.ComposeFiles holds absolute paths, and the PR template (related issue, AI tool used) isn't filled in.

[TDnorthgarden]

Thanks @TDnorthgarden, the change itself is correct and consistent with the surrounding error messages (both processFile callers are covered, %w keeps errors.Is/errors.As, and processExtends doesn't double-wrap).

That said, this is the follow-up suggested in the review of #14387, and since #14387 is still under review there is little point in landing it separately. Could you fold this commit into #14387 and close this PR?

Two reasons for doing it there:

• The motivating case (service "web": env_file is in flow style…) only exists with fix(transform): don't panic on flow-style compose files in publish rewrites #14387, so the example in this description can't be reproduced on main.
• The test here is weaker than it looks: the underlying os.ReadFile error already contains the path, so ErrorContains(err, "missing.yaml") still passes if the file name is dropped from the wrapper (I checked by removing the %s). The flow-style error from fix(transform): don't panic on flow-style compose files in publish rewrites #14387 doesn't name any file, so a test built on it will really exercise the wrapper. Please assert the exact prefix, e.g. failed to process compose file <path>: , rather than only the file name.

Two small things while you are at it: the description uses ./override.yaml whereas project.ComposeFiles holds absolute paths, and the PR template (related issue, AI tool used) isn't filled in.

Agreed — especially on the weak test: os.ReadFile already carries the path, so the old assertions passed regardless of the wrap. Folded into #14387 (df3f26d): the tests now use a real flow-style file, whose rejection does not name the file, so only the wrapped error satisfies the assertions. Closing this one as suggested.