Fix backport issues for CHANGELOG.md file

[kotwanikunal]

Signed-off-by: Kunal Kotwani [email protected]

Description

• Fixes the issues caused by CHANGELOG merge conflicts when using the backport GHA

Issues Resolved

• [BUG] CHANGELOG is incorrect across branches (main vs. 2.x) #4936

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[kotwanikunal]

@dblock @VachaShah

[VachaShah]

This should be head_template: backport/backport-<%= number %>-to-<%= base %> instead of branch_name.

[kotwanikunal]

Updated.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/5864/
• CommitID: b88162a

[VachaShah]

LGTM!

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/5866/
• CommitID: 22fbf2c

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/5869/
• CommitID: 5511703

[dblock]

With this change backports no longer have an entry in the CHANGELOG for changes. This means the 2.4.0 changelog will not include all the changes. I think this is ... a problem.

[kotwanikunal]

With this change backports no longer have an entry in the CHANGELOG for changes. This means the 2.4.0 changelog will not include all the changes. I think this is ... a problem.

We were constantly having issues with the backport GHA because of CHANGELOG which was causing oncall pain due to manual backports. There was also an issue of missing out on backport for certain versions considering the human effort involved. This process gets the workflow back to its original state, the backport PR will have the changelog verifier step fail, which can be fixed pretty easily by adding in the appropriate entry.

When backporting, folks were not moving the change to the appropriate section. This will take care of that as well.
I am also working to add a new helper workflow soon which will backport the actual line of change from the original PR to the backported PR, in the appropriate section and version.

[dblock]

I see, thanks. The backport automation is becoming a lot less automated without the implementation you suggest in the last paragraph. For project maintainers it's not too hard to amend a PR, but for contributors it means mostly manually re-creating the backport in a fork?

[kotwanikunal]

I see, thanks. The backport automation is becoming a lot less automated without the implementation you suggest in the last paragraph. For project maintainers it's not too hard to amend a PR, but for contributors it means mostly manually re-creating the backport in a fork?

Please see - #4936 (comment) 🙂
This use case only walks through backporting. Ideally, we do not want contributors to re-create a backport PR (which is already happening because of changelog conflicts).

The comment linked has a solution to both the aforementioned problems. It does the backporting without the changelog file, then backports the actual changelog line, all in a single workflow.