fix(publish): warn when push falls back from OCI 1.1 to OCI 1.0

[htoyoda18]

What I did

PushManifest silently retried in OCI 1.0 format whenever a registry rejected the OCI 1.1 manifest, leaving users unaware their artifact wasn't stored in the newer format. This was left as a TODO because internal/oci intentionally avoids importing logrus.

PushManifest now reports which OCI version was actually used instead of just success/failure, and pkg/compose/publish (which already depends on logrus) logs a warning when that differs from what was requested.

Related issue
N/A

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

[htoyoda18]

Hi @ndeloof @glours 👋 Just a friendly nudge on this one — it's been about a week with no review yet. Happy to address anything if you get a chance to take a look. Thanks!

[Copilot]

🟢 Approval recommended

The change is small and localized, with only minor wording/doc clarity issues noted.

Pull request overview

This PR makes the publish flow transparent when registries reject OCI 1.1 manifests by having internal/oci.PushManifest report which OCI version was ultimately used, and emitting a warning from pkg/compose/publish when an automatic fallback to OCI 1.0 occurs.

Changes:

• Extend internal/oci.PushManifest to return the OCI version used (in addition to the manifest descriptor).
• Update the publish path to log a warning when the default OCI 1.1 push falls back to OCI 1.0.

File summaries

File	Description
pkg/compose/publish.go	Captures the OCI version used during push and warns when falling back to OCI 1.0.
internal/oci/push.go	Returns the OCI version used from PushManifest, including in the fallback path.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[glours]

PushManifest currently returns the raw OCI version it ended up using (api.OCIVersion), and the caller reconstructs "did we fall back?" by comparing two independent fields:

if options.OCIVersion == "" && usedOCIVersion == api.OCIVersion1_0 {
    logrus.Warn(...)
}

Returning a bool (e.g. didFallback) instead would be a better fit for what's actually needed right now:

• PushManifest is the only place that knows why it picked a given version — the moment it decides to retry with api.OCIVersion1_0 is exactly the fallback event itself. A bool captures that fact directly, at the source, instead of asking the caller to re-derive it from two values that happen to correlate today.
• The caller only ever needs a yes/no signal to decide whether to warn — it never uses the specific api.OCIVersion value for anything else. A richer return type is carrying more information than any consumer reads.
• It removes a hidden coupling: today, if a second fallback tier were ever added (e.g. 1.1 → 1.0 → some legacy format), the caller's usedOCIVersion == api.OCIVersion1_0 check would need to be updated in lockstep to keep detecting it as a fallback — and nothing would force that update, since it'd still compile and just silently stop warning on the new tier. A bool set at the fallback branch itself doesn't have that failure mode.