Reject changelog bundles whose target diverges from entry targets - #3714
Closed
vishaangelova wants to merge 1 commit into
Closed
Reject changelog bundles whose target diverges from entry targets#3714vishaangelova wants to merge 1 commit into
vishaangelova wants to merge 1 commit into
Conversation
BundleBuilder took the bundle-level product target verbatim from the release-version argument and never validated it against the targets the entries themselves declare. A one-year-off release version (e.g. 2027-07-20 while every entry said 2026-07-20) therefore produced a bundle that silently rendered entries under the wrong date. Add a guardrail in BundleBuilder.BuildBundle that fails the build when a bundle-level product target is inconsistent with its entries' targets for the same product. Compatibility allows a coarser bundle target to be a component-prefix of a finer entry target (e.g. monthly rollup 2026-05 over 2026-05-15) while rejecting genuine divergence (2027 vs 2026, 9.5.0 vs 9.6.0). Adds BundleTargetConsistencyTests. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Label error. Requires exactly 1 of: automation, breaking, bug, changelog:skip, chore, ci, dependencies, documentation, enhancement, feature, fix, redesign. Found: |
Member
Author
|
It seems this PR might be irrelevant if we don’t need to use |
Member
|
@vishaangelova i believe so, also the changelog targets are aspirational (primarely used for future feature where we can share release notes ahead of time). I believe this makes them being different from the bundle target a feature not a bug.. Thanks for taking the time though, looking forward to more PR's! 😸 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A serverless breaking-change rendered on the public site under July 20, 2027 (a year in the future): https://www.elastic.co/docs/release-notes/cloud-serverless/breaking-changes#july-20-2027
Root cause: the CDN bundle
bundle/cloud-serverless/elasticsearch-2026-07-20.yamlhad a bundle-level product target of2027-07-20, even though its filename,release-date, and every one of its entries declaredcloud-serverlesstarget2026-07-20. The{changelog}directive derives its date heading frombundle.Products[0].Target(BundleLoader.GetVersionFromBundle), so the whole bundle rendered under the wrong year.The defect was possible because
BundleBuilder.BuildProductstakes the bundle-level product target verbatim from the release-version argument (--output-products/ profile{version}) and never validates it against the targets the entries themselves declare.cc: @lcawl @cotti
Fix
Add a guardrail in
BundleBuilder.BuildBundle: if a bundle-level product target is inconsistent with the targets its own entries declare for that same product, the build fails (returns an invalid result, so no bundle is written and the publish job fails loudly).Compatibility is intentionally lenient in one direction to avoid false positives:
2026-05covering an entry dated2026-05-15. ✅ allowed2027-07-20vs2026-07-20, or9.5.0vs9.6.0. ❌ errorEntries whose product carries no target, or a product the bundle doesn't declare, are not compared.
Tests
Adds
BundleTargetConsistencyTests:2027vs2026case) → bundle fails with a descriptive error, no file written2026-05over2026-05-15) → succeeds9.5.0) → succeedsFull
Elastic.Changelog.Testssuite passes (807 tests).Note
This prevents recurrence. The already-published CDN bundle still needs to be corrected separately (re-publish the cloud-serverless bundle for
elasticsearchwith the correct2026-07-20target, then invalidate the CDN cache).Made with Cursor