Conversation
Replace the three legacy shared workflows (changelog-init, changelog-submit,
changelog-upload) with the unified release-notes workflow. Bundle now fires
on GitHub release publish instead of push to main.
Changes:
- Delete changelog-init.yml, changelog-submit.yml, changelog-upload.yml
- Add release-notes.yml: unified validate/submit/bundle via docs-actions
- Add release-notes-comments.yml: PR comment upserts after release-notes run
- Add changelog-upstream-update.yml: preserve bespoke auto-entry generation
for PRs labeled changelog:upstream-update (extracted from changelog-init)
- docs/docset.yml: add release_notes.product: edot-java so CDN prefetch works
- docs/release-notes/*.md: change :::{changelog} /releases/ to
:::{changelog} edot-java (explicit product name, CDN-sourced)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The custom changelog-upstream-update.yml + .ci/changelog-upstream-update.sh are replaced by the standard release-notes-changelog-file.yml from docs-actions, which auto-generates and commits changelog entries for PRs missing one. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
pre-post-release.yml manually runs 'docs-builder changelog bundle' in the pre-release phase (with a generated description from gradlew) and removes the entries immediately after. bundle-on-release: true would fire a second empty bundle when the GitHub release is published, which is wrong. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
docs-builder infers the CDN product from the repository name (elastic-otel-java → edot-java via products.yml) and fetches best-effort. A 404 is a hint not an error, so no declaration is needed until bundles are published to the CDN. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
v1v
left a comment
v1v
left a comment
There was a problem hiding this comment.
some nits, to use the same permission strategy where top-level is empty and the ones in the jobs are defined with more granularity
|
Hey, I was looking at this and had a couple of questions (happy to be wrong on either). On the bundle strategy: On the render pages: the four |
Top-level permissions: {} with job-scoped grants is the repo's
standard permission strategy; align these two workflows with it.
Co-Authored-By: Claude <noreply@anthropic.com>
GITHUB_TOKEN-created releases do not fire the `on: release` event, so bundle-on-release in release-notes.yml never ran. Add bundle and bundle-publish jobs directly to release-step-3.yml chained after create-github-release, following the same pattern as docs-playground-release-notes-tagged-workflow. Remove the on:release trigger and bundle-on-release from release-notes.yml; id-token:write on that workflow is no longer needed. Co-Authored-By: Claude <noreply@anthropic.com>
🔍 Preview links for changed docs |
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
The old docs-builder changelog bundle step in pre-post-release.yml committed
a docs/releases/<version>.yaml file into the pre-release branch. That file was
referenced by the old release notes markdown. Now that release notes use CDN
sourcing (:::{changelog} edot-java), the committed file is dead and the step
that generates it should go. The bundle is now created post-release by
bundle-create-version@v1 in release-step-3.yml.
Also merge release-notes-comments.yml and release-notes-changelog-file.yml into
a single release-notes-downstream.yml with two jobs, as suggested in review.
Co-Authored-By: Claude <noreply@anthropic.com>
Reverts the merge of release-notes-comments.yml and release-notes-changelog-file.yml into a single file. While the consolidation makes sense locally, the onboarding guide documents these as two distinct files to copy — one for PR comments, one for auto-committing changelog entries — and teams should be able to opt into either independently. Sorry for the noise; Claude was too eager to consolidate. Co-Authored-By: Claude <noreply@anthropic.com>
Mpdreamz
changed the title
Runs .ci/changelog-bundle-description.sh before the create step and passes its output as the description input, restoring the upstream dependency version context that was lost when the pre-release bundle step was removed. Requires elastic/docs-actions#367. Co-Authored-By: Claude <noreply@anthropic.com>
| permissions: {} | ||
| jobs: | ||
| release-notes: | ||
| permissions: |
There was a problem hiding this comment.
Don't we need to include id-token: write here for the upstream "Authenticate with AWS" step?
| persist-credentials: false | ||
| - name: Generate bundle description | ||
| id: description | ||
| run: echo "text=$(.ci/changelog-bundle-description.sh)" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
Does this script return a text with newlines? If so, wouldn't it cause parsing issues later for $GITHUB_OUTPUT?
There was a problem hiding this comment.
I can confirm there are newlines in the output as it's few lines of markdown.
This branch was successfully deployed
6 participants
Replaces the three legacy changelog workflows and the upstream-update script with the unified `release-notes` reusable workflow from `elastic/docs-actions`, and moves changelog bundle creation from the pre-release phase into a post-release job that runs after the GitHub release is cut.
Affects: CI/CD workflows, release process
Prompt summary: Migrate
elastic/elastic-otel-javato use the same release-notes workflow strategy as thedocs-playground-release-notes-tagged-workflowrepo — wire bundle generation inline inrelease-step-3after the GITHUB_TOKEN-created release, instead of relying on theon: releaseevent (which GITHUB_TOKEN suppresses) or the old pre-release committed-bundle approach.Why
The legacy setup had three problems. First,
changelog-upload.ymluploaded per-PR entries to the CDN, whilechangelog-init.yml/changelog-submit.ymlhandled validation, comments, and auto-committing changelog files separately — three workflows doing what one can. Second,pre-post-release.ymlgenerated the bundle by runningdocs-builder changelog bundleand committingdocs/releases/<version>.yamlinto the pre-release branch; the release notes markdown referenced those committed files, which meant the bundle was baked before the release tag existed and couldn't be updated post-facto. Third,bundle-on-release: trueinrelease-notes.ymlwas dead code becauserelease-step-3.ymlcreates the GitHub release withGITHUB_TOKEN, and GitHub suppresses theon: releaseevent for GITHUB_TOKEN-created releases.What
Three old workflows deleted
changelog-init.yml,changelog-submit.yml, andchangelog-upload.ymlare removed, along with.ci/changelog-upstream-update.sh. Their responsibilities are covered by the new workflows below.Three new workflows added
release-notes.ymlhandles validate (on PR), upload (on push to main), and is the trigger that the two downstream workflows listen to.release-notes-comments.ymlupserts the changelog preview comment on PRs.release-notes-changelog-file.ymlauto-commits a changelog entry file for PRs that are missing one. These two downstream workflows are intentionally kept as separate files so repos can opt into each independently.Bundle creation moved post-release
release-step-3.ymlgains abundlejob (runsbundle-create-version@v1, reads from CDN, no Docker) and abundle-publishjob (OIDC-scoped upload to S3), both chained aftercreate-github-release. Thedocs-builder/setup@v1andGenerate documentation changelog bundlesteps are removed frompre-post-release.yml— the committeddocs/releases/*.yamlapproach is replaced entirely.Release notes now CDN-sourced
docs/release-notes/*.mdfiles changed from:::{changelog} /releases/(local file) to:::{changelog} edot-java(CDN product name).docs/docset.ymlgainsrelease_notes: [edot-java]so docs-builder prefetches bundles at startup.Verify