Skip to content

Standardize bundle output names; hard-error on profile output: patterns - #3856

Open
cotti wants to merge 2 commits into
feature/release-notes-onboarding-validationfrom
feature/bundle-output-convention
Open

Standardize bundle output names; hard-error on profile output: patterns#3856
cotti wants to merge 2 commits into
feature/release-notes-onboarding-validationfrom
feature/bundle-output-convention

Conversation

@cotti

@cotti cotti commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Why

Bundle output names are being standardized by convention ({product}-{version}.yaml) so every consumer — the scrubber, the CDN registry, the promotion workflow, backfill — can derive a bundle's location from product + version alone (RFC B2, closes #3774). Explicit output: patterns in profiles undermine that and, silently, let two profiles overwrite each other's target.

What

  • Bundle names derive from the profile's primary output product (first product in output_products, else products) and the version argument, in both the run and --plan (the CI bundle-create action locates the file via plan output). Invocations without a resolvable product/version (e.g. report-only) keep the changelog-bundle.yaml default.
  • Setting output: on any profile is now a hard error with a message directing removal; the field stays parseable for one release cycle so authors get the error rather than a YAML parse failure.
  • Two profiles sharing a primary output product are rejected — they would resolve to the same conventional target for any given version.
  • Example config, reference docs, and the affected test fixtures migrated to the convention.

Breaking: repositories with output: in changelog.yml profiles must remove it; their bundle file names change to the convention on the next cut.

Stack: 3/5.

Bundle names now derive by convention as {product}-{version}.yaml from
the profile's primary output product (B2, #3774), in
run and --plan alike. Profiles still setting output: get an actionable
hard error (the field stays parseable for one release cycle), and two
profiles sharing a primary product are rejected — they would silently
overwrite the same conventional target for any given version.

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
/// field remains parseable for one release cycle so authors get an actionable error rather
/// than a YAML parse failure.
/// </summary>
public string? Output { get; init; }

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also add `[Obsolete()] maybe?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 6ac9142 — added [Obsolete] with a message pointing at the convention, and suppressed CS0618 at the two intentional read sites (loader + hard-error validation) since warnings are errors here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants