[Feature Request] Backports fail often due to CHANGELOG conflicts

[jainankitk]

Is your feature request related to a problem? Please describe

The backport fails for most PR due to conflicts on CHANGELOG.md. I am wondering if there is better way around this.

Describe the solution you'd like

Maybe provide some conflict resolution hints specifically for CHANGELOG.md?

Related component

Build

Describe alternatives you've considered

No response

Additional context

No response

[dblock]

Good idea. In the case where the diff is a 1-liner, try to apply both by default.

[sandeshkr419]

Agreed @ankitkala on unnecessary blockers caused by this. The most frustrating part is users not able to edit the changelog in UI and then commit it right away. The part where you have to manually checkout the code and raise a manual backport PR is irritating. Also, chances for human errors - what if I mistakenly edit other files.

In the case where the diff is a 1-liner, try to apply both by default.

I think for changelog failures - in CI for backport PRs, we can automate this.

Probably need to trigger something like git-merge-file --union in case of conflicts in changelog, haven't checked the exact usage, but looks like we can edit our CI to do a concatenate in changelog. Also, this can also be a comment command to github-actions to run a script and resolve conflicts, and commit changes.
Reference: https://git-scm.com/docs/git-merge-file

[dblock]

[Catch All Triage - 1, 2, 3, 4, 5]

[rursprung]

coming from here: #15915 (comment) (CC @reta)

IMHO this isn't just about backports, also normal PRs need to be rebased very regularly due to changelog conflicts. i'm not contributing that often here, but it's somewhat annoying 🙈

quoting what i wrote in the other PR:

i'm a big fan of having a changelog, but it's causing a lot of merge conflicts here 🙁
i've seen another repo (don't remember which, but i have a vague feeling that it was even in the opensearch org?) which had a subfolder where you created one file per PR for the changelog and some automated tooling then collected all of that together and merged it into the main changelog file for the release (and deleted the other files). maybe that might be an idea here as well to avoid the merge conflicts?

as a detail: i guess you could then do the equivalent of CHANGELOG.md and CHANGELOG-3.0.md by having a dedicated folder for the upcoming release and once you're ready to release that you remove the normal folder and rename the one for the upcoming release.

[andrross]

i've seen another repo (don't remember which, but i have a vague feeling that it was even in the opensearch org?)

@rursprung I suspect you're referring to OpenSearch-Dashboards: https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/changelogs

Full details about that solution are here. We should definitely look at moving to that approach if it is working well for the dashboards repo.

[dbwiddis]

Most common problem: Everyone's adding their Change log entry to the bottom of the list. That's why they conflict.

Simple fix: Add your entry in numeric sorting order. If higher numbered PRs have already been merged this will minimize conflicts.

[andrross]

While somewhat disruptive in the short term, moving to the process implemented by OpenSearch_Changelog_Workflow will completely eliminate these merge conflict problems. OpenSearch-Dashboards is already using that approach. @dbwiddis @jainankitk What do you think?

[dbwiddis]

While somewhat disruptive in the short term

We can minimize the disruption by timing the switch with a minor version bump.

I'm not clear from that proposal how we handle the 2.x and 3.x sections separately.