[Release] Add release.yml for release notes automation

[ZilongX]

Signed-off-by: Zilong Xia zilongx@amazon.com

Description

• Add release.yml to enable the release notes automation for OSD
  (Ref : https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes)

• 2.4.0 would be a good opportunity for us to test out this new release feature

• Also we will need to label each PR properly in order to category changes in the right place (we may need a label cleaning and consolidation first)

• Test release notes created in fork (automatically just on a click !)
  https://github.com/ZilongX/OpenSearch-Dashboards/releases/tag/2.4.0

Issues Resolved

Resolved #2677

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[ashwin-pc]

Hey @ZilongX, I've called out some concerns in the original issue about this approach. Since the initial changelog was introduced in a rush without proper discussion, I don't want us to slam another solution in without coming to a conclusion on that thread. There seem to be a lot of good ways to do it, and this might be one too, but let's settle on it before pushing this in.

[seraphjiang]

Hey @ZilongX, I've called out some concerns in the original issue about this approach. Since the initial changelog was introduced in a rush without proper discussion, I don't want us to slam another solution in without coming to a conclusion on that thread. There seem to be a lot of good ways to do it, and this might be one too, but let's settle on it before pushing this in.

@ashwin-pc

Don't see any conflict to try. this approach has no additional conflict of workload added. it is very much doable, wait for last step to verify the gap.

It is two-ways door, we could revert if result is not we want.

[kavilla]

Hey @ZilongX, I've called out some concerns in the original issue about this approach. Since the initial changelog was introduced in a rush without proper discussion, I don't want us to slam another solution in without coming to a conclusion on that thread. There seem to be a lot of good ways to do it, and this might be one too, but let's settle on it before pushing this in.

Tbh, the changelog is an organization decision

[ashwin-pc]

Don't see any conflict to try. this approach has no additional conflict of workload added. it is very much doable, wait for last step to verify the gap.

@seraphjiang You are right, it is a 2 way door. But i disagree with the workload added. This flow only addresses release notes and not changelog, So even with this solution, we dont really close the gap for changelogs pain. Secondly, it relies on good PR titles and labels. Thats 67 PR's we need to label and edit for the generated notes to work. something i'm sure @AMoo-Miki might not be happy to add to his release checklist.

From your comment it looks like you want to use this as an experiment to test and see if this solves part of our release process pain, and for that i think we can get the answer to that from the POC @ZilongX has implemented in https://github.com/opensearch-project/opensearch-dashboards-functional-test. Its also has a much smaller blast radius and can give us a good idea of the pro's and cons of this approach.

Also given that we are at code freeze for 2.4. Adding this to the already messy changelog problem might cause more harm than good.

[ZilongX]

@opensearch-project/opensearch-dashboards-core maintainers poke for a re-review following the discussion, let's proceed the auto generation of release notes (for experimentation for now) if no other concerns

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.66%. Comparing base (14af23a) to head (dc3b6d7).
Report is 1 commits behind head on main.

❗ Current head dc3b6d7 differs from pull request most recent head 2dc48aa

Please upload reports for the commit 2dc48aa to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2732      +/-   ##
==========================================
- Coverage   67.44%   66.66%   -0.78%     
==========================================
  Files        3442     3219     -223     
  Lines       67816    61448    -6368     
  Branches    11027     9417    -1610     
==========================================
- Hits        45740    40967    -4773     
+ Misses      19409    18234    -1175     
+ Partials     2667     2247     -420     

Flag	Coverage Δ
Linux_1	?
Linux_2	?
Linux_3	?
Linux_4	?
Windows_1	?
Windows_2	?
Windows_3	?
Windows_4	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ashwin-pc]

@ZilongX I've called out my reasons for holding off on this change for now. Let me know if you disagree with my reasons. My assumptions could be wrong, but my goal is to make sure we dont merge this in without a plan to solve our original pain point (changelog and release notes generation)

[ashwin-pc]

Moving this to draft for now until.

[kavilla]

Thanks for opening @ZilongX! It will seem we are moving forward with this proposal here: opensearch-project/.github#156.

If you have an feedback please comment there! Thanks!

[github-actions]

❌ Invalid Changelog Heading

The '## Changelog' heading in your PR description is either missing or malformed. Please make sure that your PR description includes a '## Changelog' heading with proper spelling, capitalization, spacing, and Markdown syntax.

[seraphjiang]

Let's try the github build-in release note generate to see if we could expedite the process

[seraphjiang]

let's get this in and try, no need to wait for test, since this is just config file for release note generator