bake: reject targets inside target blocks

[amarkdotdev]

Summary

• reject the attribute when it is used inside a block
• point users toward blocks for grouped bake targets
• add a regression test for issue Invalid bake target syntax still builds #2437

Testing

• go test ./bake -count=1

Closes #2437

[amarkdotdev]

Gentle ping on this one. It's a small, self-contained fix for #2437: bake now rejects a targets attribute used inside a target block (it belongs in a group block) with a clear "Unsupported argument" diagnostic, instead of silently building. DCO and labeler are green, and go test ./bake -count=1 passes locally (full package suite, including the new TestTargetDisallowsGroupTargetsAttribute).

The build / validate / e2e / codeql workflows are sitting in the "action required" state pending a maintainer's approval to run on this PR. Could a maintainer approve the run and take a look? Happy to address anything that comes up. Closes #2437.

[amarkdotdev]

@tonistiigi @crazy-max Gentle ping — rebased on latest master and go test ./bake/... still passes locally.

Small fix for #2437: bake now rejects targets inside a target block (belongs in a group block) with a clear diagnostic instead of silently building. CI was 159/160 green before the rebase.

Would appreciate a look when you have a moment.

[crazy-max]

Thanks for tackling this. I'm not convinced this fully closes #2437 yet.

This patch special-cases one invalid attribute, targets inside a target block, and returns a hard parse error after the normal HCL parse succeeds. That fixes the reproducer from #2437, but the issue thread was also about the broader validation contract, including the earlier concern that strict schema validation could be breaking and the later suggestion to warn instead.

So can we make the intended contract explicit with tests for the relevant bake inputs? At minimum I'd expect coverage showing this behaves correctly for merged files and JSON bake syntax too, since otherwise this is easy to mistake for a complete validation fix when it is really a targeted guard.

[amarkdotdev]

@crazy-max Fair point — this is intentionally a narrow guard for the #2437 reproducer, not the broader schema validation we discussed in the issue thread. I held off on strict validation given the breaking-change concern you raised there.

Pushed 66aadfa with tests that spell out what this covers today:

• HCL and JSON bake syntax
• merged files (including HCL + JSON together)
• group blocks with targets still parse fine

Contract for this PR: targets inside a target block is a hard parse error with a clear diagnostic, instead of being silently ignored. If you'd rather this be a warning for now (per your earlier note on the issue), happy to switch — just say the word.