Fix publish short-form port mappings

[false200]

What I did

Fixed docker compose publish so it works with short-form port mappings like ${DASHBOARD_PORT:-3000}:3000.

The issue was in the publish scan path. It was loading a non-interpolated Compose file back into types.Project, and that caused short-form port entries to fail decoding. This change keeps that path as raw YAML model data instead.

I also added:

• a unit test for this case in pkg/compose/publish_test.go
• an e2e regression test in pkg/e2e/publish_test.go

Related issue

Fixes #13672

(not mandatory) A picture of a cute animal, if possible in relation to what you did)

[false200]

Hi maintainers,

I looked into this and was able to reproduce it.

The failure comes from the publish scan path, not from normal Compose parsing. That path reloads a non-interpolated Compose file back into types.Project, and short form port entries like ${DASHBOARD_PORT:-3000}:3000 end up failing there with:

'services[whoami].ports[0]' expected a map or struct, got "string"

I put together a fix that keeps that path as raw YAML model data instead of rebinding it into types.Project, which makes docker compose publish accept the short form port mapping again.

I also verified it with:

• a focused unit test
• an e2e publish --dry-run regression test

On the patched build, the repro passes for me instead of throwing the decode error.

[glours]

Sounds good to me, thanks for the fix 🙏

[glours]

The fallback pattern in the last commit silently discards errors from LoadWithContext, any real config error would go unnoticed and fall through to the raw model path. The two paths also produce different YAML representations, making the secret scanner's behavior inconsistent.
The 3rd commit (LoadModelWithContext only) is the right direction. The sensitive data detection issue should be fixed at a higher level rather than papering over it with a fragile try/fallback.