Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Enhanced Changelog Format Options #608

Open
ArvinJ-H opened this issue Feb 17, 2024 · 14 comments
Open

Feature Request: Enhanced Changelog Format Options #608

ArvinJ-H opened this issue Feb 17, 2024 · 14 comments
Labels
enhancement New feature or request

Comments

@ArvinJ-H
Copy link

Is your feature request related to a problem? Please describe.
not really

Describe the solution you'd like
Currently, Changie supports a standard changelog format, but I'm interested in having additional formatting options to cater to different project structures (monorepo). Specifically, I propose two new formats:

Plugin/Module-Centric Format:

## Plugin-name
## Plugin-name/Module-name
### Added
- Thing added
- Thing added
### Fixed
- Thing fixed
- Thing fixed

or

Category-Centric Format with Module Reference:

### Added
- Module1: Thing added
- Module2: Thing added
### Fixed
- Module1: Thing fixed
- Module2: Thing fixed

Describe alternatives you've considered
Each project have their own changelog, run changie batch as normal, but replace changie merge with a custom script

Additional context
Closed the other two ticket since they are no longer applicable.

@ArvinJ-H ArvinJ-H added the enhancement New feature or request label Feb 17, 2024
@miniscruff
Copy link
Owner

I believe the first one is already possible by using components. I can make an example for you later if needed. And the latter might be possible by adding the component to the change format and skipping the component format. Again, I can try it tomorrow.

@ArvinJ-H
Copy link
Author

ah i did try to play with components, it did generated something like

### Added
- Module1: Thing added
- Module2: Thing added
### Fixed
- Module1: Thing fixed
- Module2: Thing fixed

But it was prepended to the project specific CHANGELOG.

It will be awesome if you can provide an example

@miniscruff
Copy link
Owner

Right, components are configured per project if you are using both. However during the merge process we still generate separate changelogs. If you only want to build one changelog you would not use projects, maybe you would use components instead.

I'm not sure I fully understand what you want the final output to be as what I was going to suggest is what you tried.

It sounds like you are using a monorepo, but want a single changelog where components determine which app or system the change took place in. Which is possible using components, without projects.

If the apps are independently released and thus have separate changelogs, you can use the projects feature to handle that. But you will get one changelog per project.

There is not a way to create one changelog while using projects as the whole point of that config is to generate multiple changelogs.

@ArvinJ-H
Copy link
Author

ArvinJ-H commented Feb 21, 2024

ah I see what you mean, sorry it was a bit confusing.

Is it possible to have projects and components coexist, when only one projects requires components during changie new command?

ie. only project plugin requires additional components input

projects:
  - label: 
    key: u1
    changelog: ui/u1/CL.md
  - label: u2
    key: u2
    changelog: ui/u2/CL.md
  - label: plugin
    key: plugin
    changelog: CHANGELOG.md

components:
    - plugin-1
    - plugin-2
    - plugin-3

@miniscruff
Copy link
Owner

Currently no, projects keep the same global options as all the others. I was on the fence about adding options to the projects configuration as it would definitely greatly expand the complexity of the config. As it is, practically every option in the global config level would be applicable to at the projects level and I wasn't really prepared for that.

@ArvinJ-H
Copy link
Author

oh okay.

what was the reason it was not implemented and could this be a feature request?

@miniscruff
Copy link
Owner

I was unsure if this kind of functionality was going to be useful or not, and I saw how complicated the kind configs got with custom prompts per kind and wasn't sure how much that was to explode the complexity when I started doing the same idea in the project config.

Its quite possible that between projects and some of the formatting I may just need to readjust the config from the ground up.

For me, it wouldn't make sense to just add the one config you need and skip all the other parts that would also apply to projects. But yea, doing all of that would be a lot of work.

@ArvinJ-H
Copy link
Author

ArvinJ-H commented Mar 1, 2024

maybe a bug or user error, when changie is set up something like this

...default settings
kindFormat: "### {{.Kind}}"
fragmentFileFormat: '{{.Component}}-{{.Custom.Issue}}-{{.Time.Format "2006-01-02"}}'

components:
- ...

batch auto seems to be creating the changelog by looping through the unreleased folder, generates change log similar to this (notice the duplicated Changed and Added), the fragments in the unreleased folder have the exact same change kind order

## v1.0.0 - 2024-03-01

### Changed
- Placeholder

### Removed
- Placeholder
- Placeholder

### Fixed
- Placeholder

### Improved
- Placeholder
- Placeholder

### Added
- Placeholder
- Placeholder
- Placeholder

### Changed
- Placeholder

@miniscruff
Copy link
Owner

miniscruff commented Mar 2, 2024

maybe a bug or user error, when changie is set up something like this

...default settings
kindFormat: "### {{.Kind}}"
fragmentFileFormat: '{{.Component}}-{{.Custom.Issue}}-{{.Time.Format "2006-01-02"}}'

components:
- ...

batch auto seems to be creating the changelog by looping through the unreleased folder, generates change log similar to this (notice the duplicated Changed and Added), the fragments in the unreleased folder have the exact same change kind order

## v1.0.0 - 2024-03-01

### Changed
- Placeholder

### Removed
- Placeholder
- Placeholder

### Fixed
- Placeholder

### Improved
- Placeholder
- Placeholder

### Added
- Placeholder
- Placeholder
- Placeholder

### Changed
- Placeholder

Ok I think I reproduced the issue, without a Component header it does look funky.
With this config change:

componentFormat: '### {{.Component}}'
kindFormat: '* {{.Kind}}'

My steps look like this:

changie new -c UI -k Added -b "placeholder" -m Issue=5
changie new -c UI -k Changed -b "placeholder" -m Issue=5
changie new -c UI -k Removed -b "placeholder" -m Issue=5
changie new -c Backend -k Added -b "placeholder" -m Issue=5
changie new -c Backend -k Removed -b "placeholder" -m Issue=5
changie batch auto
cat ./.changes/$(changie latest).md

Output:

## v4.0.0 - 2024-03-01
### UI
* Added
* placeholder
* Changed
* placeholder
* Removed
* placeholder
### Backend
* Added
* placeholder
* Removed
* placeholder

With this config:

kindFormat: '### {{.Kind}}'
changeFormat: '* {{.Component}} {{.Body}}'

It gives the, not quite correct output of:

## v6.0.0 - 2024-03-01
### Added
* UI placeholder
### Changed
* UI placeholder
### Removed
* UI placeholder
### Added
* Backend placeholder
### Removed
* Backend placeholder

That is, it still groups components first, and then kind. Ideally it would group both UI and backend components under the added/removed kinds since we don't want the component headers.

@ArvinJ-H
Copy link
Author

ArvinJ-H commented Mar 3, 2024

It gives the, not quite correct output of:

## v6.0.0 - 2024-03-01
### Added
* UI placeholder
### Changed
* UI placeholder
### Removed
* UI placeholder
### Added
* Backend placeholder
### Removed
* Backend placeholder

That is, it still groups components first, and then kind. Ideally it would group both UI and backend components under the added/removed kinds since we don't want the component headers.

Ideally we would like the change log to be formatted in this way, is there any work around to not output duplicated Kinds title?

Also, I did for forgot to mention we will have multiple unique entry for the same components, thanks for acknowledge this

@miniscruff
Copy link
Owner

miniscruff commented Mar 3, 2024

Ideally we would like the change log to be formatted in this way, is there any work around to not output duplicated Kinds title?

Also, I did for forgot to mention we will have multiple unique entry for the same components, thanks for acknowledge this

Its not that the kinds is being duplicated, its that its trying to output one component at a time, its just that the component format is empty so there is no output for it. The solution here would be to skip sorting/grouping by component if the component format is empty, or some config flag, that way the default kind sorting would include multiple components worth of changes. That is this block here

changie/core/change.go

Lines 49 to 58 in 3e31b28

// Start by sorting by component index
if len(s.config.Components) > 0 && a.Component != b.Component {
for _, c := range s.config.Components {
if a.Component == c {
return true
} else if b.Component == c {
return false
}
}
}
.

If instead of checking if components is enabled by len(comps)>0, we instead check if len(compFormat)>0 I think it will fix itself. Let me see.

Edit: Modified the code locally and re-ran the repro steps.

## v7.0.0 - 2024-03-02
### Added
* UI placeholder
* Backend placeholder
### Changed
* UI placeholder
### Removed
* UI placeholder
* Backend placeholder

That is what you are looking for right?

Edit 2: One more point above is that I actually think we should still consider sorting by component in this scenario, but after kind, such that the component updates are grouped together in the kind update. Right now its sorted by time in my test script.

@miniscruff
Copy link
Owner

Ok, so to summarize.

  1. Plugin/Module-Centric Format is supported already if you provide components with a component format?
  2. Category-Centric Format with Module Reference is not supported without a feature/bug fix allowing components without a header to maintain kind sorting?

I can make a separate ticket for 2 with a more specific summary and get to that soon. But want to clarify the first one is good to go or answer any questions on that one.

@ArvinJ-H
Copy link
Author

ArvinJ-H commented Mar 3, 2024

  1. yes Plugin centric is working as expected, the final form is a bit different to the example I gave, but it is working fine.
  2. yes, Kind sorting/combine would be something I call it in a ticket

Just one more request... when the changie config set to components only, can we have an option to also export changelog individually, maybe an optional config like this?

component
- UI
- ui/changelog.md

@miniscruff
Copy link
Owner

  1. yes Plugin centric is working as expected, the final form is a bit different to the example I gave, but it is working fine.

    1. yes, Kind sorting/combine would be something I call it in a ticket

Just one more request... when the changie config set to components only, can we have an option to also export changelog individually, maybe an optional config like this?

component
- UI
- ui/changelog.md

oops forgot to reply, if you need more then one changelog you have to use the projects feature. You could swap components for projects and get that. Components do not have that options and I don't see why I would add them now that we have the projects system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants