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

[cotti]

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.

[lcawl]

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

I think this is problematic since we have multiple repos contributing to the same products and their releases could occur on the same day (e.g. any of the repos putting bundles into https://us-east-1.console.aws.amazon.com/s3/buckets/elastic-docs-v3-changelog-bundles?region=us-east-1&prefix=bundle/cloud-serverless/&showversions=false could occur on the same day, which is why we currently name them based on the repo they're derived from). Ditto for https://us-east-1.console.aws.amazon.com/s3/buckets/elastic-docs-v3-changelog-bundles?region=us-east-1&prefix=bundle/cloud-hosted/&showversions=false where you have bundles dropping from multiple repos potentially on the same day for ECH releases.

Perhaps this means you need to change the pattern to {repo}-{product}-{version}.yaml?

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

Even if you don't allow teams to specify their filename, I think you might need to keep it around just for the folder path (and test it, not sure if a folder alone is currently accepted). For example, in the case where we're publishing from bundles that exist locally in the repo and we have multiple pages that relate to different products (e.g. Serverless and Observability and Security in docs-content or ECE and ECH in cloud), the changelog directive pulls all the bundles from a specified path (i.e. profiles need to route bundles to specific paths, which is currently accomplished by prepending a path to the filename in the output setting). I don't think you can get away from that until you get to the point where you stop storing and publishing bundles locally.

[github-actions]

Requesting changes: --plan currently reports an output_path that can differ from the actual bundle filename in source: github_release profile mode, which can break CI consumers that rely on plan output.

---

What is this? | From workflow: PR Review

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

Comments that could not be inline-anchored

src/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cs:1047

--plan derives output_path from the raw input.ProfileArgument, but the real bundle path in profile mode is built from the resolved version (filterResult.Version) in ProcessProfile.

For source: github_release this diverges because runtime normalizes from the fetched tag (ExtractBaseVersion(release.TagName), e.g. v9.2.0 -> 9.2.0), while plan currently keeps v9.2.0/latest as-is. That can make CI look for a file that bundle never writes.

Please make plan and run share the sa…

Fixed: --plan's output_path now mirrors ProcessProfile's version normalization (ExtractBaseVersion) and output-directory precedence for source: github_release profiles, so it matches the file the real bundle run writes. Verified with a new plan-vs-actual-run parity test plus corrected existing plan assertions.