Skip to content

1.5.2 - Enforce strict changelog entry types

Choose a tag to compare

@allanmcarvalho allanmcarvalho released this 20 Oct 23:40
· 28 commits to 1.x since this release

Changed

  • Strict structured output for AI changelog entries: The release changelog generation now requests strict structured output from AI providers, so only supported Conventional Commit type values are produced.

    • If an AI provider returns an invalid changelog entry type, the release process now aborts with an error.
    • The error message includes:
      • the originating commit identifier (commit hash),
      • the invalid type value received, and
      • the full list of allowed type values.
  • Strict agent execution: ReleaseChangelogAgent now runs in strict mode (via #[Strict], in addition to the existing #[UseCheapestModel]). This improves validation/acceptance behavior and reduces the likelihood of non-conformant structures being used.

  • Improved validation diagnostics: LaravelAiReleaseChangelogGenerator now throws a RuntimeException with more specific context when validation fails due to an invalid type:

    • commit hash,
    • a debug/truncated representation of the returned type,
    • and the full expected set self::TYPES.

Documentation

  • Changelog configuration guidance was updated to reflect that the release process requests strict structured output from AI providers.

Testing

  • Unit tests were expanded to verify:
    • the generator requests a strict OpenAI JSON schema (strict: true) and constrains entries[].type to the allowed enum:
      • feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
    • invalid type values (unknown category, null, or non-string) are rejected and cause generate() to throw a RuntimeException that includes the commit hash, the invalid value, and the expected allowed types.

Compatibility / Migration

  • This is primarily a stricter validation change.
  • If your AI provider/workflow previously returned changelog type values outside the allowed set, the release process will now fail early instead of accepting them.
  • No public configuration keys or APIs are described as changed; migration is only relevant for workflows that relied on previously non-compliant AI outputs.