Repository navigation
release serverless: let the configuration decide the products of an entry - #4481
theletterf wants to merge 1 commit into
Conversation
…ntry Remove the EntryProducts override that stamped cloud-serverless and the service product on every synthesized entry. Kibana now sets products.implies for its team labels and Elasticsearch maps stateful and serverless to products with both as default, so the shared resolver gives each entry the right products: labels with implies, else products.default, else the profile's output products. A stateful Elasticsearch PR gets elasticsearch only and the per-product rules.bundle drops it from the Serverless bundle. Fixes elastic/docs-eng-team#1039 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RyiyHmDHcUFt8rjMNR8TBm
![infra-vault-gh-plugin-prod[bot]](https://avatars.githubusercontent.com/u/6764390?s=60&v=4){kind=small}
| var arguments = new BundleChangelogsArguments | ||
| { | ||
| Profile = svc.Profile, | ||
| EntryProducts = [.. ServerlessPromotion.EntryProductIds(svc).Select(id => new ProductArgument { Product = id })], |
There was a problem hiding this comment.
Severity: P3 (Low)
Handle an intentionally empty serverless bundle when removing this override. If the Elasticsearch submodule range contains only stateful PRs, its entries are now correctly excluded, but BuildAndWriteBundle treats that empty result as an error. Serverless then exits with code 1 before setting the bundle outputs, preventing publication even if the primary repository produced valid release notes. Treat a fully excluded range as a successful skip in this automation path, while preserving genuine bundling errors.
Generated by Libra. React with 👍 or 👎 to give feedback on this comment.
There was a problem hiding this comment.
Known and decided on #4461: Martijn asked to keep "No changelog entries remained after applying rules.bundle filter" as an error rather than a warning, so this PR does not change it. A range of the Elasticsearch submodule with only stateful PRs would fail the run today, and that was the case before this PR too whenever the filter emptied a bundle. If we want the automation to treat a fully excluded range as a skip, that is a separate change to release serverless, and I would rather take it with Martijn than fold it in here.
Docs preview (local build)Handbook preview: https://docs-v3-preview.elastic.dev/elastic/docs-builder/pull/4481/ |
|
@Mpdreamz PTAL |
This branch was successfully deployed
1 participant
Affects: Release notes
Prompt summary: Remove the
EntryProductsoverride fromrelease serverlessnow that the product configuration of Kibana and Elasticsearch decides the products of an entry. Last step of the order agreed in #4461; keep the PR a draft until the production refs include the new configs.Context
#4378 made
release serverlessstampcloud-serverlessplus the service product on every synthesized entry, after 13 Kibana entries came out with the wrong product: a team label routed them tosecurityorobservabilityalone. #4469 solved that in configuration instead: one shared product resolver andproducts.implies. Kibana now setsimpliesfor its team labels (elastic/kibana#298020) and Elasticsearch mapsstatefulandserverlessto products with both products as default (elastic/elasticsearch#162051). Both are merged.This PR removes the override, which is what was left of #4461.
What
release serverlessno longer passesEntryProducts;ServerlessPromotion.EntryProductIdsandServerlessProductare gone.BundleChangelogsArguments.EntryProductsandGitRangeEntryResolutionOptions.EntryProductsare gone. A synthesized entry gets the products of the configuration: labels (withimplies), elseproducts.default, else the profile's output products. The require-a-label rule is unchanged.Effect at the next promotion
Team:*PR gets its solution product pluskibanaandcloud-serverlessthroughimplies; a PR without a team label gets the defaultskibanaandcloud-serverless.statefulPR getselasticsearchonly and the per-productrules.bundledrops it from thecloud-serverlessbundle as disjoint; aserverlessPR getscloud-serverless; a PR with neither gets both defaults. That is the behaviour Pete asked for in elastic/docs-eng-team#1039.Do not merge before
The promotion reads each service's
docs/changelog.ymlat the promoted ref, and main is live on the edge image at the next promotion. Merge only after the production refs of Kibana and Elasticsearch include elastic/kibana@6cf1ebfd4 and elastic/elasticsearch@04a5c187d, or a promotion of an older ref drops the team-labelled Kibana PRs. Review can start now; the merge waits for those refs.Verify
dotnet test --project tests/Elastic.Changelog.TestsRemoved the two tests that pinned the override (
EntryProductIds_AreTheServerlessProductAndTheServiceProduct,InferredEntry_EntryProducts_ReplaceLabelDerivedProducts). The resulting behaviour is covered by the range-bundle tests #4469 added, which already ran without the override:InferredEntry_Products_LabelsWinThenImpliesThenDefaults,InferredEntry_Products_AStackOnlyLabelKeepsThePullRequestOutOfTheServerlessBundle,InferredEntry_Products_DefaultsCarryTheirLifecycleAndNoVersion.Docs: no change. "Product resolution order" in
configure-ref.mdalready describes this order and names no exception forrelease serverless.Not run against a real promotion.
Fixes elastic/docs-eng-team#1039. Related to elastic/docs-eng-team#1059.
🤖 Generated with Claude Code
https://claude.ai/code/session_01RyiyHmDHcUFt8rjMNR8TBm