Open
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds configurable release-date behavior across changelog bundling: new nullable Sequence Diagram(s)sequenceDiagram
participant User
participant CLI as ChangelogCommand
participant Config as ChangelogConfigurationLoader
participant GitHub as GitHubReleaseService
participant Bundler as ChangelogBundlingService
participant Output as Bundle YAML
User->>CLI: run gh-release [--release-date]
CLI->>GitHub: FetchReleaseFromUrl()
GitHub-->>CLI: GitHubReleaseInfo (PublishedAt?)
CLI->>Bundler: CreateChangelogsFromReleaseArguments (ReleaseDate?)
alt ReleaseDate provided
Bundler->>Bundler: validate yyyy-MM-dd
else if release.PublishedAt present
Bundler->>Bundler: derive ReleaseDate from PublishedAt (UTC)
else
Bundler->>Bundler: use UTC today (if not suppressed)
end
Bundler->>Output: write bundle.yaml with resolved release-date
User->>CLI: run bundle [--no-release-date | --release-date]
CLI->>Config: ParseBundleConfiguration()
Config-->>CLI: BundleConfiguration / profiles (ReleaseDates?)
CLI->>Bundler: BundleChangelogsArguments (SuppressReleaseDate, ReleaseDate?)
Bundler->>Bundler: resolve final ReleaseDate (existing -> explicit -> auto unless suppressed)
Bundler->>Output: write bundle.yaml with/without release-date
Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/tooling/docs-builder/Commands/ChangelogCommand.cs (1)
551-595:⚠️ Potential issue | 🟠 MajorPropagate GitHub
published_atinbundle --release-versionmode.Line 575 fetches the release, but that timestamp is never forwarded; Line 852 then passes
null, so bundling falls back to UTC “today” instead of the release publish date.Proposed fix
+using System.Globalization; ... var release = await releaseService.FetchReleaseAsync(resolvedOwner, resolvedRepo, releaseVersion, ctx); if (release == null) { collector.EmitError(string.Empty, $"Failed to fetch release '{releaseVersion}' for {resolvedOwner}/{resolvedRepo}. Ensure the tag exists and credentials are set."); return 1; } + + if (!noReleaseDate && string.IsNullOrWhiteSpace(releaseDate) && release.PublishedAt.HasValue) + { + releaseDate = DateOnly + .FromDateTime(release.PublishedAt.Value.UtcDateTime) + .ToString("yyyy-MM-dd", CultureInfo.InvariantCulture); + }Also applies to: 851-853
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tooling/docs-builder/Commands/ChangelogCommand.cs` around lines 551 - 595, You fetch the GitHub release via GitHubReleaseService.FetchReleaseAsync and parse notes, but you never forward the release.PublishedAt timestamp; update the code so that when a release is fetched (variable release) you capture release.PublishedAt and pass it into the downstream bundling call that currently gets null (the bundle creation / bundling invocation invoked later when building the bundle from prs/parsedNotes). Concretely: after FetchReleaseAsync and before setting prs from parsedNotes, store release.PublishedAt (or a UTC DateTime derived from it) and thread that value into the bundle creation API call (replace the null currently passed) so the bundling uses the release publish date instead of falling back to today.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Elastic.Documentation.Configuration/ReleaseNotes/BundleLoader.cs`:
- Around line 250-251: The conflict resolution for ShowReleaseDates in
BundleLoader.cs is currently order-dependent because mergedShowReleaseDates
falls back to first.Data?.ShowReleaseDates when multiple differing values exist;
change this to a deterministic fallback (e.g., false) so that
mergedShowReleaseDates = showReleaseDatesValues.Count == 1 ?
showReleaseDatesValues[0] : false, replacing the reference to
first.Data?.ShowReleaseDates and ensuring the resolution uses the
showReleaseDatesValues collection and a fixed default rather than the first
bundle's value.
In `@src/tooling/docs-builder/Commands/ChangelogCommand.cs`:
- Around line 851-853: The code currently sets ReleaseDate = noReleaseDate ?
null : releaseDate which loses the intent of --no-release-date; instead add a
boolean property (e.g., SuppressReleaseDate) to the object being constructed and
set it from noReleaseDate while leaving ReleaseDate to reflect only an explicit
date (Description = description, ReleaseDate = releaseDate /* or null only when
truly absent */, SuppressReleaseDate = noReleaseDate). Then update the bundling
service’s release-date resolution branch to check the new SuppressReleaseDate
flag (in addition to ReleaseDate) and treat SuppressReleaseDate as explicit
suppression of any resolved date.
---
Outside diff comments:
In `@src/tooling/docs-builder/Commands/ChangelogCommand.cs`:
- Around line 551-595: You fetch the GitHub release via
GitHubReleaseService.FetchReleaseAsync and parse notes, but you never forward
the release.PublishedAt timestamp; update the code so that when a release is
fetched (variable release) you capture release.PublishedAt and pass it into the
downstream bundling call that currently gets null (the bundle creation /
bundling invocation invoked later when building the bundle from
prs/parsedNotes). Concretely: after FetchReleaseAsync and before setting prs
from parsedNotes, store release.PublishedAt (or a UTC DateTime derived from it)
and thread that value into the bundle creation API call (replace the null
currently passed) so the bundling uses the release publish date instead of
falling back to today.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 4749e90b-7d10-4460-a2f4-a386a0109aae
📒 Files selected for processing (22)
config/changelog.example.ymldocs/cli/changelog/bundle.mddocs/cli/changelog/gh-release.mddocs/syntax/changelog.mdsrc/Elastic.Documentation.Configuration/Changelog/BundleConfiguration.cssrc/Elastic.Documentation.Configuration/ReleaseNotes/Bundle.cssrc/Elastic.Documentation.Configuration/ReleaseNotes/BundleLoader.cssrc/Elastic.Documentation.Configuration/ReleaseNotes/ReleaseNotesSerialization.cssrc/Elastic.Documentation/ReleaseNotes/Bundle.cssrc/Elastic.Markdown/Myst/Directives/Changelog/ChangelogInlineRenderer.cssrc/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cssrc/services/Elastic.Changelog/Configuration/ChangelogConfigurationLoader.cssrc/services/Elastic.Changelog/GitHub/GitHubReleaseService.cssrc/services/Elastic.Changelog/GitHub/IGitHubReleaseService.cssrc/services/Elastic.Changelog/GithubRelease/GitHubReleaseChangelogService.cssrc/services/Elastic.Changelog/Rendering/Asciidoc/ChangelogAsciidocRenderer.cssrc/services/Elastic.Changelog/Rendering/ChangelogRenderContext.cssrc/services/Elastic.Changelog/Rendering/ChangelogRenderingService.cssrc/services/Elastic.Changelog/Rendering/Markdown/IndexMarkdownRenderer.cssrc/services/Elastic.Changelog/Serialization/ChangelogConfigurationYaml.cssrc/tooling/docs-builder/Commands/ChangelogCommand.cstests/Elastic.Markdown.Tests/Directives/ChangelogBasicTests.cs
coderabbitai
bot
added
documentation
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/services/Elastic.Changelog/GithubRelease/GitHubReleaseChangelogService.cs (1)
344-361:⚠️ Potential issue | 🟠 MajorDon't pass GitHub
published_atthroughReleaseDateas an override.
BundleChangelogstreats any non-emptyReleaseDateas the explicit override path before it preserves an existing bundle date. DerivingreleaseDatehere means re-bundling an existing bundle will replace its stored date withpublished_at, which breaks the "preserve existing release dates" behavior. The GitHub date needs to stay a fallback that is applied only after the existing bundle metadata has been checked.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/services/Elastic.Changelog/GithubRelease/GitHubReleaseChangelogService.cs` around lines 344 - 361, The code sets releaseDate to GitHub's published_at and always passes it into BundleChangelogsArguments.ReleaseDate, which forces BundleChangelogs to treat it as an explicit override; instead only pass a ReleaseDate when the user explicitly provided one (input.ReleaseDate). In GitHubReleaseChangelogService.cs remove or avoid assigning release.PublishedAt into releaseDate for the bundleArgs; ensure BundleChangelogsArguments.ReleaseDate is left null/empty unless input.ReleaseDate is non-empty so the bundler can preserve existing bundle metadata and only fall back to published_at later when appropriate.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Elastic.Markdown/Myst/Directives/Changelog/ChangelogBlock.cs`:
- Around line 355-363: The auto-discovery only checks ".yml" filenames (the
candidates array in ChangelogBlock.cs) so "changelog.yaml" is missed; update the
candidates creation in the method that returns the discovered changelog path to
include the corresponding ".yaml" variants (e.g., add
Path.GetFullPath(Build.DocumentationSourceDirectory.ResolvePathFrom("changelog.yaml"))
and the "../changelog.yaml" and "../docs/changelog.yaml" equivalents) so
Build.ReadFileSystem.File.Exists can find either extension when resolving the
changelog file.
- Around line 295-313: LoadConfiguration currently uses
ShowReleaseDatesPattern()/regex to scan the file and can pick up a
top-level/profile show_release_dates instead of the bundle-level setting;
replace the regex scan with proper YAML parsing (e.g., load the YAML into a
node/object and read bundle.show_release_dates) inside LoadConfiguration so you
explicitly read the "bundle" mapping and its "show_release_dates" value
(preserve boolean parsing and fallback behavior), remove or stop relying on
ShowReleaseDatesPattern() for this lookup, and update the config auto-discovery
logic used by ResolveConfigPath() to include ".yaml" as a candidate extension in
addition to ".yml".
---
Outside diff comments:
In
`@src/services/Elastic.Changelog/GithubRelease/GitHubReleaseChangelogService.cs`:
- Around line 344-361: The code sets releaseDate to GitHub's published_at and
always passes it into BundleChangelogsArguments.ReleaseDate, which forces
BundleChangelogs to treat it as an explicit override; instead only pass a
ReleaseDate when the user explicitly provided one (input.ReleaseDate). In
GitHubReleaseChangelogService.cs remove or avoid assigning release.PublishedAt
into releaseDate for the bundleArgs; ensure
BundleChangelogsArguments.ReleaseDate is left null/empty unless
input.ReleaseDate is non-empty so the bundler can preserve existing bundle
metadata and only fall back to published_at later when appropriate.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 676f30b1-90b2-443f-9c2c-b490178563c9
📒 Files selected for processing (8)
src/Elastic.Documentation.Configuration/ReleaseNotes/BundleLoader.cssrc/Elastic.Markdown/Myst/Directives/Changelog/ChangelogBlock.cssrc/Elastic.Markdown/Myst/Directives/Changelog/ChangelogInlineRenderer.cssrc/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cssrc/services/Elastic.Changelog/GithubRelease/GitHubReleaseChangelogService.cssrc/services/Elastic.Changelog/Rendering/ChangelogRenderingService.cssrc/tooling/docs-builder/Commands/ChangelogCommand.cstests/Elastic.Markdown.Tests/Directives/ChangelogBasicTests.cs
🚧 Files skipped from review as they are similar to previous changes (4)
- src/Elastic.Documentation.Configuration/ReleaseNotes/BundleLoader.cs
- src/services/Elastic.Changelog/Rendering/ChangelogRenderingService.cs
- src/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cs
- src/tooling/docs-builder/Commands/ChangelogCommand.cs
coderabbitai
bot
removed
the
documentation
coderabbitai
bot
added
feature
and removed
documentation
coderabbitai
bot
added
documentation
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Elastic.Markdown/Myst/Directives/Changelog/ChangelogBlock.cs`:
- Around line 315-318: The code only reads config.Bundle?.ShowReleaseDates so
profile-level settings are ignored; change the logic to first check the
profile-specific value in the deserialized ChangelogDirectiveConfigYaml (e.g.
config.Bundle?.Profiles?[currentProfile]?.ShowReleaseDates) and only fall back
to config.Bundle?.ShowReleaseDates if the profile value is null/unspecified,
then assign the resolved boolean to ShowReleaseDates; locate the current profile
identifier from the build/profile context (e.g. Build.Profile?.Name or
equivalent) and use it to index into config.Bundle.Profiles when implementing
this override.
- Around line 338-348: The code currently trims the leading '/' into trimmedPath
before calling Path.IsPathRooted, which lets Unix absolute paths bypass the
absolute-path guard; fix by not stripping the leading slash and perform the
rooted check on the original ConfigPath (e.g., replace trimmedPath usage with
the raw ConfigPath in the Path.IsPathRooted call) or explicitly check for
Unix-style leading '/' (ConfigPath.StartsWith("/")) before proceeding; keep the
subsequent ResolvePathFrom/GetFullPath/ValidateConfigCandidate flow and still
call EmitError("Changelog config path must not be an absolute path.") and return
null when the path is absolute.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 54c39158-6794-4b2c-be4a-e232ace55ba4
📒 Files selected for processing (1)
src/Elastic.Markdown/Myst/Directives/Changelog/ChangelogBlock.cs
coderabbitai
bot
added
feature
and removed
documentation
coderabbitai
bot
added
documentation
coderabbitai
bot
added
feature
and removed
documentation
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/tooling/docs-builder/Commands/ChangelogCommand.cs (1)
777-797:⚠️ Potential issue | 🟠 Major
--planbypasses the new release-date validation.Lines 777-797 return before Lines 799-826 run, so
bundle --planaccepts invalid input like--no-release-date --release-date ..., bad date formats, and profile-mode release-date flags. That makes plan mode disagree with the real bundle execution path.Also applies to: 799-826
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/tooling/docs-builder/Commands/ChangelogCommand.cs` around lines 777 - 797, The plan branch in ChangelogCommand.cs builds a BundleChangelogsArguments and calls service.PlanBundleAsync but returns before the release-date validation run later for the real bundle path, so --plan can accept invalid release-date/profile flags; to fix, invoke the same validation routine (the release-date/profile validation used in the non-plan flow) before returning in the plan branch or reuse the central validation method that checks releaseDate, --no-release-date, formats and profile-mode flags (ensure the same checks that run after line ~799 are executed here), then only proceed to SetOutputAsync/return 0 if validation passes; reference BundleChangelogsArguments, service.PlanBundleAsync and githubActionsService.SetOutputAsync to locate the code to update.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cs`:
- Around line 475-476: ProcessProfile() currently computes
profileSuppressReleaseDate with profileSuppressReleaseDate =
!(profile.ReleaseDates ?? config.Bundle.ReleaseDates ?? true), but later code
(around where SuppressReleaseDate is set) reapplies the bundle default and
therefore lets bundle.release_dates:false override a profile's true; fix this by
using the resolved profile-level boolean (the result of profile.ReleaseDates ??
config.Bundle.ReleaseDates ?? true) when assigning the profile's
SuppressReleaseDate property (i.e., set SuppressReleaseDate to the negation of
that resolved value) so the explicit profile.ReleaseDates value is honored
instead of being overwritten by the bundle default.
---
Outside diff comments:
In `@src/tooling/docs-builder/Commands/ChangelogCommand.cs`:
- Around line 777-797: The plan branch in ChangelogCommand.cs builds a
BundleChangelogsArguments and calls service.PlanBundleAsync but returns before
the release-date validation run later for the real bundle path, so --plan can
accept invalid release-date/profile flags; to fix, invoke the same validation
routine (the release-date/profile validation used in the non-plan flow) before
returning in the plan branch or reuse the central validation method that checks
releaseDate, --no-release-date, formats and profile-mode flags (ensure the same
checks that run after line ~799 are executed here), then only proceed to
SetOutputAsync/return 0 if validation passes; reference
BundleChangelogsArguments, service.PlanBundleAsync and
githubActionsService.SetOutputAsync to locate the code to update.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 1d68b56c-0e1d-4ceb-9656-cd707b13011c
📒 Files selected for processing (9)
config/changelog.example.ymldocs/syntax/changelog.mdsrc/Elastic.Documentation.Configuration/Changelog/BundleConfiguration.cssrc/services/Elastic.Changelog/Bundling/ChangelogBundlingService.cssrc/services/Elastic.Changelog/Configuration/ChangelogConfigurationLoader.cssrc/services/Elastic.Changelog/Serialization/ChangelogConfigurationYaml.cssrc/tooling/docs-builder/Commands/ChangelogCommand.cstests/Elastic.Changelog.Tests/Changelogs/BundleChangelogsTests.cstests/Elastic.Changelog.Tests/Changelogs/ChangelogConfigurationTests.cs
🚧 Files skipped from review as they are similar to previous changes (5)
- src/services/Elastic.Changelog/Serialization/ChangelogConfigurationYaml.cs
- src/services/Elastic.Changelog/Configuration/ChangelogConfigurationLoader.cs
- config/changelog.example.yml
- docs/syntax/changelog.md
- src/Elastic.Documentation.Configuration/Changelog/BundleConfiguration.cs
Contributor
Author
|
Following discussion with @cotti I've pushed a commit with the following change in da54410:
Completed Changes:
Key Features Implemented:
Verification:
|
coderabbitai
bot
added
documentation
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
3 participants
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.
Relates to #3030
This PR is a follow-up to #3066
Overview
This PR implements comprehensive release date automation for changelog bundles, focusing on CI/CD workflows while maintaining flexibility for different use cases. The feature allows release dates to be automatically populated or omitted based on configuration.
Key Features
🚀 Automatic Release Date Population
changelog gh-releaseautomatically uses the GitHub releasepublished_atdate--release-date YYYY-MM-DDflag for explicit date specification🎛️ Configurable Release Date Population
bundle.profiles.<name>.release_datesfor per-profile customizationbundle.release_datesto change default behavior in changelog config--no-release-dateto explicitly suppress date population🔧 Profile Mode Enhancement
changelog bundlebehave identicallyMajor Files Changed
Configuration & Domain Models
BundleConfiguration.cs- AddedShowReleaseDatesproperty (default:false)Bundle.cs- AddedShowReleaseDatesproperty to domain modelChangelogConfigurationYaml.cs- YAML serialization supportChangelogConfigurationLoader.cs- Configuration parsing logicCore Services
ChangelogBundlingService.cs- Auto-population and profile resolution logicGitHubReleaseChangelogService.cs- GitHubpublished_atdate integrationGitHubReleaseService.cs- Extended GitHub API response parsingRendering Engine
ChangelogRenderingService.cs- Bundle-level rendering controlIndexMarkdownRenderer.cs- Conditional Markdown outputChangelogAsciidocRenderer.cs- Conditional AsciiDoc outputChangelogInlineRenderer.cs- Directive rendering updatesCLI Interface
ChangelogCommand.cs- Added--release-dateand--no-release-dateflags with validationDocumentation
bundle.md,gh-release.md)changelog.md)contribute/changelog.md)changelog.example.yml)Usage Examples
CLI Commands
Configuration
bundle.release_datesserves as a global default that affects all bundle operations, whether using profiles or command-line flags (unless overridden by profile-level setting or explicity command option).This implementation prioritizes CI/CD automation while providing flexible control over release date rendering, supporting both automated workflows and manual release processes.
Generative AI disclosure
Tool(s) and model(s) used: claude-sonnet-4