Automate consolidated release notes creation

[gaiksaya]

Is your feature request related to a problem? Please describe

Right now we are using a temporary script https://github.com/opensearch-project/opensearch-build/blob/main/scripts/release-notes/release-notes.sh to consolidate release notes. Its is a very painful process to keep create consolidated release notes for each release and manually keep making change.

Describe the solution you'd like

We would like to create release notes generation workflow integrated with the python code base that would take care of collecting all plugins' components release notes and creating a consolidate one as per the standards.

Describe alternatives you've considered

Keep doing it manually

Acceptance Criteria

• The release notes generation should be automated completely along with formatting.
• Only manual thing to do would be adding release highlights, experimental features, etc
• Throw a warning if the plugin release notes do not align with the standards Assume that all components' release notes are up to the standards.
• Code should also contain tests cases testing various scenarios.

[SachinSahu431]

I would like to give it a try.

[gaiksaya]

Thanks @SachinSahu431
Let us know if you need any help or clarification. Would suggest to start by researching a bit and posting the approaches on this issue before moving to implementation.
Assigning this issue to you.
Thanks again!

[prudhvigodithi]

The repo already have a release_notes_workflow and leverages MarkdownTableWriter, @SachinSahu431 please take a look and explore if this can be re-used. Thanks

[SachinSahu431]

Current Progess:

Currently for obtaining links for individual release-notes links, the temporary script, uses many if-else conditions (like this, this) and hardcoding the plugin names. I tried to create a new python script and obtained these links without hardcoding any plugin names, and it works well (few exceptions mentioned below). Results are as follows: results

Next step:

With all the release notes links obtained, the next step is to organize them based on their categories. This will be my next task. I would be happy to discuss any suggestions you have about this.

Further plan:

The command to generate this report will be very similar to how the release_notes_workflow is used.

For release notes check:
./release_notes.sh check manifests/2.10.0/opensearch-2.10.0.yml --date 2023-07-26

For release notes compile:
./release_notes_compile.sh compile manifests/2.10.0/opensearch-2.10.0.yml --output compiled_release_notes.md

Help required:

I see some repos which are to be skipped while compiling release notes.

Also, OSD plugins are not being captured currently, and might require hardcoding. I was able to capture only these repos as of now.

Please help me identify any more repos that must be handled carefully.
Thank you!

[SachinSahu431]

Hi! @peterzhuamazon @gaiksaya @prudhvigodithi
I've developed a Python script that gathers release notes for all plugin components and compiles them into a unified Markdown file. You can access the script here and compiled file here.

✅ Here are the key features:

1. It generates a table presenting the availability status of release notes, resembling the structure in release_notes_workflow. This table includes links for quick access. You can view an example here.

2. The script creates this table with URLs for the first time and saves it for future use.

3. If any new category is introduced, apart from the predefined RELEASENOTES_CATEGORIES, it is appended to the end of the consolidated markdown file. See an example here.

4. The script can handle variations in the naming of headings through the use of heading_mapping. For example, it can accommodate 'Feat,' 'Feature,' and 'Features' seamlessly.

5. The script utilizes the Markdown renderer mistune to resolve any markdown rendering issues.

❓I need some help with the following:

1. In the file opensearch.job-scheduler.release-notes-2.8.0.0.md, there is a category named 'Added.' Could you please advise on how to handle this?

2. I've noticed that release notes are often presented in various formats. For example:

### Refactoring\n- Add class for loading mapping templates in bulk ([#1550](https://github.com/opensearch-project/observability/pull/1550))\n
and
### Refactoring\nChange package for Strings.hasText ([#314](https://github.com/opensearch-project/geospatial/pull/314))\n
and
### Maintenance\n* [AUTO] Increment version to 2.9.0-SNAPSHOT ([#690](https://github.com/opensearch-project/notifications/pull/690))\n\n
etc.

Currently, the script only supports the last format. Could you kindly suggest how we should handle the other formats?

Thank you!

[gaiksaya]

❓I need some help with the following:

In the file opensearch.job-scheduler.release-notes-2.8.0.0.md, there is a category named 'Added.' Could you please advise on how to handle this?

I've noticed that release notes are often presented in various formats. For example:

We are assuming that whatever release notes are being consolidated are upto the standards. However, it would be great if we can flag the release notes that are not following standard guidelines. We can collect the out of the ordinary categories and improper formats and add it at the end of the consolidated release notes under NON-COMPLAINT section.
Regarding formats, is it possible to accommodate all possibilities? (\n, \n\n, \n*) if not, we can put them under non-complaint section as well.

[SachinSahu431]

Thanks for the feedback @gaiksaya!

I have updated the script to handle all kinds of formats now. Also, a non-compliant section has been added (see example). Other improvements include handling empty headings (just like ### Features given here).

Could you please elaborate on workflow and test cases as discussed in the acceptance criteria?

Describe the solution you'd like

We would like to create release notes generation workflow integrated with the python code base that would take care of collecting all plugins' components release notes and creating a consolidate one as per the standards.

Acceptance Criteria

• Code should also contain tests cases testing various scenarios.

Thank you!