Feaure:Create a new github workflow for auto changelog generation.

[utkarsh232005]

Feature Request: Automatic Changelog Generation on Every Release

Overview

Implement an automated changelog generation workflow that triggers whenever a new version of the project is released.

The workflow should support all release types including:

• Patch releases (x.x.PATCH)
• Minor releases (x.MINOR.x)
• Major releases (MAJOR.x.x)

Whenever a new release/version is published, the system should automatically trigger an autoChangeLog workflow responsible for generating the changelog for that released version.

---

Expected Behavior

Trigger Conditions

The workflow should automatically execute when:

• A new GitHub release is created
• A new version tag is pushed
• A version bump occurs

Supported examples:

v1.0.1
v1.1.0
v2.0.0

---

Workflow Responsibilities

The autoChangeLog workflow should:

• Detect the latest released version
• Compare changes with the previous release
• Collect commits automatically
• Categorize changes properly:
  • Features
  • Bug Fixes
  • Improvements
  • Refactoring
  • Documentation
• Generate a clean markdown changelog
• Automatically update CHANGELOG.md
• Generate release notes for the current version
• Optionally commit the updated changelog back to the repository
• Support semantic versioning

---

Suggested Changelog Format

# Changelog

## v2.1.0

### Features
- Added Kubernetes cluster monitoring

### Fixes
- Fixed Docker container crash issue

### Improvements
- Improved CLI performance

---

Suggested Implementation

Possible tools/services:

• GitHub Actions
• Conventional Commits
• semantic-release
• auto-changelog
• release-please

---

Additional Notes

The workflow should integrate seamlessly with the existing release/versioning system and automatically handle all future releases without requiring manual intervention.

[Yuvraj-Sarathe]

I am working on this!

Please assign me to this issue!

[utkarsh232005]

@CodeRabbit plan

[coderabbitai]

Coding Plan

Summary

• Use git-cliff as the changelog generation tool for its flexibility with non-conventional commits and powerful categorization via regex patterns
• Trigger the workflow on release: [published] events to integrate seamlessly with the existing manual publish.yml workflow
• Generate incremental changelog entries (latest release only) and prepend them to CHANGELOG.md to build up history over time
• Commit changes back to main using the existing GH_PAT secret pattern, keeping the workflow consistent with other repository automation

Design Choices

Design Choice 1: Which changelog generation tool should be used?

Options Considered:

1. auto-changelog — Simple npm package, works without conventional commits, minimal setup
2. git-cliff — Fast Rust-based tool, highly configurable templates, regex-based categorization, works with or without conventional commits
3. release-please — Google's tool, full automation, but requires conventional commits and may conflict with existing manual publish workflow
4. semantic-release — Comprehensive automation, requires strict conventional commits setup

Chosen Option: 2

Rationale: Option 2 (git-cliff): Provides flexible regex-based categorization that can work with the project's non-standardized commit messages while offering a clear upgrade path to conventional commits. It's fast, well-maintained, and integrates easily with GitHub Actions.

Design Choice 2: What event should trigger the autoChangeLog workflow?

Options Considered:

1. release: [published] — Triggers when the existing publish.yml creates a GitHub Release
2. push: tags — Triggers when version tags are pushed
3. workflow_run — Triggers after publish.yml completes

Chosen Option: 1

Rationale: Option 1 (release: [published]): Since publish.yml already creates a GitHub Release as its final step, triggering on the release event provides a clean, single trigger point that integrates naturally with the existing workflow and avoids duplicate runs.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Initialize Changelog Infrastructure

Set up the foundational files required for automated changelog generation, including the initial changelog file and the configuration for the changelog generation tool.

Task 1: Create Initial CHANGELOG.md

Create the changelog file that will be automatically updated by the workflow.

• Create CHANGELOG.md at the repository root with a header structure and placeholder for the project name
• Include a brief introductory note explaining the file is auto-generated and follows semantic versioning
• The initial file should be minimal—just the header and format guide—as actual release entries will be generated by the workflow

Task 2: Add git-cliff Configuration

Configure git-cliff to categorize commits and generate properly formatted changelog entries.

• Create cliff.toml at the repository root with commit parsing rules
• Define commit groups for the required categories: Features, Bug Fixes, Improvements, Refactoring, Documentation
• Configure regex patterns to match common commit prefixes (feat, fix, docs, refactor, perf, chore) as well as keyword-based fallbacks for non-conventional commits
• Set up the changelog body template to produce the markdown format specified in the ticket (## version header, ### category subheaders, - bullet items)
• Configure tag pattern to match semantic version tags (v*)

🤖 Prompt for AI agents

Set up the two foundational files needed for changelog automation:
`CHANGELOG.md` and `cliff.toml`.

**Task 1: Create `CHANGELOG.md` at the repository root**
- Add a top-level header with the project name placeholder
- Include a brief introductory note that the file is auto-generated and follows
semantic versioning
- Keep the file minimal (header and format guide only); actual release entries
will be appended by the workflow

**Task 2: Create `cliff.toml` at the repository root**
- Define commit groups matching the required categories: Features, Bug Fixes,
Improvements, Refactoring, and Documentation
- Configure regex patterns to match conventional commit prefixes (`feat`, `fix`,
`docs`, `refactor`, `perf`, `chore`) as well as keyword-based fallbacks for
non-conventional commit messages
- Set up the changelog body template to output: `## version` header, `###
category` subheaders, and `- bullet` list items
- Configure the tag pattern to match semantic version tags (`v*`)

Phase 2: Create the autoChangeLog Workflow

Implement the GitHub Actions workflow that triggers on releases, generates the changelog, and commits it back to the repository.

Task 1: Create the Workflow File

Set up the workflow structure with appropriate triggers and permissions.

• Create .github/workflows/auto-changelog.yml with release: types: [published] trigger
• Add a guard condition to ensure it only runs for the main branch
• Configure checkout action with fetch-depth: 0 to access full git history (required for comparing tags)
• Use secrets.GH_PAT for checkout (consistent with existing workflows) to enable pushing commits back
• Set up git user identity for the bot (matching the pattern in publish.yml)

Task 2: Implement Changelog Generation Logic

Add the steps that generate the changelog and commit it back to the repository.

• Install git-cliff using the official GitHub Action (orhun/git-cliff-action)
• Configure git-cliff to generate changelog for the latest tag compared to the previous tag
• Prepend the new release section to the existing CHANGELOG.md (preserving history)
• Commit the updated CHANGELOG.md with a descriptive message (e.g., docs: update changelog for vX.Y.Z)
• Push the commit to the main branch
• Add error handling to gracefully skip if no new commits are found between tags

Task 3: Add Workflow Documentation

Document the new workflow and its integration with the release process.

• Add a comment block at the top of the workflow file explaining its purpose and trigger conditions
• Update README.md with a brief note about automatic changelog generation (optional, in the relevant section if one exists)
• The workflow should be self-documenting with clear step names

🤖 Prompt for AI agents

Create the GitHub Actions workflow file `.github/workflows/auto-changelog.yml`
that triggers on published releases, generates an incremental changelog entry
using git-cliff, and commits it back to the repository.

**Task 1: Workflow structure and trigger setup**
- Add a comment block at the top of the file explaining its purpose and trigger
conditions
- Set the trigger to `release: types: [published]`
- Add a guard condition so the job only runs for the main branch
- Use `actions/checkout` with `fetch-depth: 0` to access the full git history
(required for tag comparison)
- Authenticate checkout using `secrets.GH_PAT` to enable pushing commits back
- Configure git user identity for the bot, matching the pattern used in
`publish.yml`

**Task 2: Changelog generation and commit steps**
- Install and run git-cliff using the official `orhun/git-cliff-action` GitHub
Action
- Configure git-cliff to generate the changelog for the latest tag compared to
the previous tag
- Prepend the newly generated release section to the existing `CHANGELOG.md`,
preserving prior history
- Commit the updated `CHANGELOG.md` with a descriptive message following the
pattern `docs: update changelog for vX.Y.Z`
- Push the commit to the main branch
- Include error handling to gracefully skip the commit/push steps if no new
commits are found between tags

**Task 3: README documentation (optional)**
- If a relevant section exists in `README.md`, add a brief note about automatic
changelog generation

Research

This is the kdm-cli project (Kubernetes and Docker Monitoring CLI) at version 1.2.1. The .github/workflows/ directory contains 11 workflow files, with publish.yml being the sole release mechanism—manually triggered via workflow_dispatch, it bumps the version with npm version, pushes tags, publishes to npm, and creates a GitHub Release with auto-generated notes. There is no existing CHANGELOG.md, no changelog tooling dependencies, no conventional commits enforcement, and no release configuration files. The project uses secrets.GH_PAT for authenticated git operations and softprops/action-gh-release@v1 for release creation.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Set up the two foundational files needed for changelog automation:
`CHANGELOG.md` and `cliff.toml`.

**Task 1: Create `CHANGELOG.md` at the repository root**
- Add a top-level header with the project name placeholder
- Include a brief introductory note that the file is auto-generated and follows
semantic versioning
- Keep the file minimal (header and format guide only); actual release entries
will be appended by the workflow

**Task 2: Create `cliff.toml` at the repository root**
- Define commit groups matching the required categories: Features, Bug Fixes,
Improvements, Refactoring, and Documentation
- Configure regex patterns to match conventional commit prefixes (`feat`, `fix`,
`docs`, `refactor`, `perf`, `chore`) as well as keyword-based fallbacks for
non-conventional commit messages
- Set up the changelog body template to output: `## version` header, `###
category` subheaders, and `- bullet` list items
- Configure the tag pattern to match semantic version tags (`v*`)
===============================================================================

Task: 2

Create the GitHub Actions workflow file `.github/workflows/auto-changelog.yml`
that triggers on published releases, generates an incremental changelog entry
using git-cliff, and commits it back to the repository.

**Task 1: Workflow structure and trigger setup**
- Add a comment block at the top of the file explaining its purpose and trigger
conditions
- Set the trigger to `release: types: [published]`
- Add a guard condition so the job only runs for the main branch
- Use `actions/checkout` with `fetch-depth: 0` to access the full git history
(required for tag comparison)
- Authenticate checkout using `secrets.GH_PAT` to enable pushing commits back
- Configure git user identity for the bot, matching the pattern used in
`publish.yml`

**Task 2: Changelog generation and commit steps**
- Install and run git-cliff using the official `orhun/git-cliff-action` GitHub
Action
- Configure git-cliff to generate the changelog for the latest tag compared to
the previous tag
- Prepend the newly generated release section to the existing `CHANGELOG.md`,
preserving prior history
- Commit the updated `CHANGELOG.md` with a descriptive message following the
pattern `docs: update changelog for vX.Y.Z`
- Push the commit to the main branch
- Include error handling to gracefully skip the commit/push steps if no new
commits are found between tags

**Task 3: README documentation (optional)**
- If a relevant section exists in `README.md`, add a brief note about automatic
changelog generation

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[utkarsh232005]

@Yuvraj-Sarathe make sure the changelogs are written inside /docs folder also follow the structure of the folder version docs management

[utkarsh232005]

refer #25 please
Thankyou 😊