[Mpdreamz]

Summary

Onboards Elasticsearch to the automated release notes workflow, set up like elastic/kibana#294816. Elasticsearch already has a docs/changelog.yml that maps labels, areas and products. This PR adds the workflows that use it:

• .github/workflows/release-notes.yml, with require-impact-action: true.
• .github/workflows/release-notes-comments.yml.
• bundle.backports.labels: [backport] in docs/changelog.yml. A backport PR then counts as its original pull request when the unified release notes bundle a commit range.

Do not merge yet. Homer's changelog files break the new checks. See "Decision needed" below: Elasticsearch has to choose between two options first.

Release automation

Release automation is already handled for serverless and unified stack releases. Elasticsearch is set to features.release-notes: dra in products.yml in docs-builder, which hooks it up to the unified stack release automation. No action is needed in this repository.

What release-notes.yml gets Elasticsearch

• release-notes / validate on every PR. Validates the PR labels against docs/changelog.yml: a type label (such as >bug), or a skip label (such as >non-issue). It also validates any docs/changelog/*.yaml file the PR adds or changes.
• Sync to S3 on push to main. Changelog entries and amend files merged to main sync automatically, so the team can correct published release notes by editing an entry or adding an amend file.
• Impact and Action for breaking changes. A PR labelled >breaking or >breaking-java fails unless its description has ## Impact and ## Action sections, or its changelog entry has impact: and action: fields. Keep them in one place; a description section that differs from the entry file's field fails as a conflict.

release-notes-comments.yml keeps a single PR comment up to date that tells the author what is wrong and how to fix it. It runs from workflow_run, so it also works for PRs from forks.

Once the workflow has run on a few PRs, add release-notes / validate as a required check on main.

Decision needed: the changelog files Homer writes

Today Homer (elastic/elasticsearch-infra, GitHubChangelogUtils) commits docs/changelog/<pr>.yaml to each PR, and elasticsearch-ci/validate-changelogs (Gradle validateChangelogs, also part of precommit) checks them against Elasticsearch's own schema. Those files use the legacy schema (summary, area, breaking:, highlight:). docs-builder rejects unknown keys. Run on a real Homer file, docs/changelog/162890.yaml:

Unknown key 'area'. Did you mean 'areas'?
Unknown key 'summary'. Valid keys: action, areas, description, feature-id, highlight, impact, issues, link, pr, products, prs, source-redirect, …

With this workflow, release-notes / validate validates changelog files that a PR changes whether or not they are required, so every PR that Homer writes a file to would fail. The push-to-main sync would also upload the same files (it only logs a warning when it cannot read one), and range bundling then fails on the PR that owns an unparseable file. There are 745 files in docs/changelog today.

There are two ways out.

A. No changelog files; labels only. The release notes come from PR labels, title and description, which the workflow validates and enforces.

• Turn off Homer's changelog handling for Elasticsearch.
• Remove the validate-changelogs Buildkite step and the precommit dependency on validateChangelogs.
• Remove or move the legacy docs/changelog/*.yaml files before the sync on main goes live. Check first whether the Gradle release tooling or the 8.x branches still read them.

B. Keep per-PR files, in the docs-builder schema.

• Homer writes the docs-builder schema (title, type mapped through pivot.types, areas, prs, products, impact/action), or a Buildkite step runs docs-builder changelog add and commits the file.
• Set require-changelog-file: true on the release-notes job to get the "add a changelog file" comment and validation.
• We do not suggest release-notes-changelog-file.yml: bot commits reset CI on a repository with this many PRs, and it does not work for forks.
• Convert or remove the legacy files, as in A.

Labels

The checks use the labels Elasticsearch already has. Run against this docs/changelog.yml with docs-builder:

PR labels	Result
>bug, :Core/Infra/Metrics	ok, type bug-fix
>breaking, :Core/Infra/Core	ok, type breaking-change (needs Impact and Action)
>enhancement	ok
>non-issue	skipped
>bug, :Distributed/Health	ok
>tech-debt, :Core/Infra/Metrics	fails: no matching type label

Gaps to talk about, from comparing the repository's labels with docs/changelog.yml:

• Type labels with no mapping and no skip rule: >tech-debt, >new-aggregation, >new-field-mapper. A PR with only one of these fails validation (>tech-debt verified above). Either map them to a type or add them to rules.create.exclude.
• Types without a label: known-issue and security are defined in pivot.types but nothing maps a label to them.
• Product label: serverless is mapped to cloud-serverless, but the repository has no serverless label (only stateful). A PR with no product label gets the defaults from products.default, so this is not a failure today.
• Area labels: 19 : labels have no pivot.areas entry, for example :Distributed/HDFS, :Distributed/GeoIP database, :Security/Profile, :Core/Infra/System Indices. An unmapped area does not fail validation, so those PRs get no area in the release notes.

Open items

• Elasticsearch picks A or B above.
• Decide the labelling gaps above.
• Add release-notes / validate as a required check once it is stable.

🤖 Generated with Claude Code

[github-actions]

🔍 Preview links for changed docs

⏳ Building and deploying preview... View progress

This comment will be updated with preview links when the build is complete.

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[elasticsearchmachine]

Pinging @elastic/core-docs (Team:Docs)

[elasticsearchmachine]

Pinging @elastic/developer-docs (:Docs/Dev)

[theletterf]

@Mpdreamz, Kibana asked to stop the release notes check and the "Changelog labels needed" comment on draft PRs. elastic/docs-actions#442 adds an opt-in skip-drafts input for this. The two suggestions here opt Elasticsearch in, the same way as elastic/kibana#300949.

Because this branch is on your fork, I could not open a separate PR against it. Please apply the suggestions after docs-actions#442 is in v1. Before that, the workflow would fail on the unknown input.

---

Generated by Claude Code

[theletterf]

@brianseeders @arpadkiraly @georgewallace @charlotte-hoblik Please review, thanks!

[lcawl]

The changelog.yml update LGTM, thanks!