Skip to content

Fix inconsistent changelog config overrides #2775

@lcawl

Description

@lcawl

Describe the bug

Background

While testing #2773 I discovered a bug #2774

I then started an AI chat about where else the commands have not been updated to correctly interact with the new or changed configuration options. This issue contains that analysis.

Summary

The changelog bundle command has multiple places where options in the
changelog.yml configuration file silently override explicit command-line
flags.

Bugs found

1. Profile --output is silently ignored (medium severity)

When using profile mode (changelog bundle <profile> <version>), if the
profile has an output pattern configured, any explicit --output flag
passed on the command line is silently discarded.

Repro:

docs-builder changelog bundle elasticsearch-release 9.2.0 \
  --config ~/my/changelog.yml \
  --output /custom/path.yaml    # silently ignored

Root cause (ChangelogBundlingService.cs, ProcessProfile):

// profile config wins even when user passed --output
Output = outputPath ?? input.Output,

Fix: Reverse the precedence so CLI wins:

Output = input.Output ?? outputPath,

2. --directory is silently ignored when it equals the current directory (low severity)

ApplyConfigDefaults treats "directory equals current working directory"
as "directory was not specified", so it overwrites the value with
config.bundle.directory. This means --directory . or
--directory $(pwd) are silently replaced by the config value.

Repro:

# changelog.yml has: bundle.directory: /some/other/path
docs-builder changelog bundle \
  --directory .    # silently replaced by /some/other/path
  --input-products "elasticsearch 9.3.0 *"

Root cause (ChangelogBundlingService.cs, ApplyConfigDefaults):

if ((string.IsNullOrWhiteSpace(directory) || directory == Directory.GetCurrentDirectory())
    && !string.IsNullOrWhiteSpace(config.Bundle.Directory))
{
    directory = config.Bundle.Directory;
}

Also, the CLI pre-collapses null to current dir before passing to the
service (Directory = directory ?? Directory.GetCurrentDirectory()), so
the service cannot distinguish "not specified" from "explicitly set to .".

Fix:

  • Pass Directory = directory (nullable) from the CLI layer.
  • In ApplyConfigDefaults: only use config when input.Directory == null.
  • Resolve to Directory.GetCurrentDirectory() at the 8 downstream call
    sites that need a concrete path (lines 141, 145, 149, 272, 331, 356,
    362, 364 of ChangelogBundlingService.cs), noting that line 272 is in
    ProcessProfile which runs before ApplyConfigDefaults.

3. extract.release_notes / extract.issues config settings are never applied (very low severity / separate gap)

The changelog add command documents that extract.release_notes and
extract.issues in changelog.yml can be set as defaults, but
ChangelogCreationService.ApplyConfigDefaults returns the input unchanged.
The CLI's own defaults (always true) are used instead.

This is the inverse direction (config ignored, not overriding), but is
noted here for completeness. The comment in ChangelogCreationService.cs
says "Apply config defaults to input (for extract_release_notes,
extract_issues)" but the implementation does nothing.


Priority order

  1. Profile --output override — fires in normal automated/CI workflows
    when both a profile and --output are used together.
  2. --directory override — requires an unusual invocation to trigger
    (explicitly passing current directory as --directory).
  3. Extract settings not wired — no override occurs, config is just
    unused; low impact.

Expected behavior

My general expectation is that the options in the changelog configuration file are used as defaults. Anything specified on the command line should override that behaviour.

Steps to reproduce

I have not tested these assertions yet.
When I tested the broken --no-resolve I used the files in elastic/kibana#250840 so the same is likely possible for the remaining bugs.

Tooling

  • docs-builder
  • migration tooling
  • I'm not sure

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions