Release tracker for component repos

[zelinh]

Is your feature request related to a problem? Please describe

When we were launching release, it's hard for us to know if each release component has any new fixes, commits or updates from last release. Right now it would require us to look into each repo and check their commit history on certain branch.

In addition, If they have any new commits after last release on the same branch, we would also need and enforce them to provide release notes and it would be better if they merge it before we finalize the release candidates.

There are a lot of back and forth efforts if we found one repo has updates but they didn't backport the changes to the specific branch or provide the release notes on time, which may at the worst case, delay the release.

We would like to have a generalized report to track any changes on each release plugins since last release so it would be easier for us to work with plugin teams for the release.

Describe the solution you'd like

Acceptance criteria: A generalized report to track any changes on each release plugins since last time release on the same branch.

Describe alternatives you've considered

Keep doing things manually.

Additional context

No response

[bbarani]

[Triaged] We will start adding functionality to report the changes corresponding to a release soon. This feature is added to track the changes on a specific repo in order to be informed on the changes for a release.

[prudhvigodithi]

My thought is this a perquisite opensearch-project/opensearch-plugins#142, as right now the branch for a specific release is not constant, a plugin source branch for a specific release is an important key here.

Example for 2.2 release 2.x branch should be the source (https://github.com/opensearch-project/OpenSearch/blob/2.x/buildSrc/version.properties) for all plugins, so a script can be fired to check against 2.x branch, any inconsistencies with branching may not give the accurate results in terms of commits, example if a plugin using main for 2.x and other's using 2.x then the possible solution is a matrix to use [plugin, release_branch] and fire the script.

The other factor that needs to be considered is excluding the version increment commit as for sure the version increment will be done moving forward after every release.

Thoughts @bbarani @zelinh @peterzhuamazon ?

[gaiksaya]

Agreed about the branching strategy consistency. Let's try to avoid whole [release_branch] param. Few questions:

1. When will this data be generated? (assuming just before a RC is created or code complete date or code freeze date?)
2. What about the commits/ bug fixes that go in during the release testing phase? Will the data be generated again before the release or will it be too late to make any changes?

[prudhvigodithi]

@gaiksaya the idea is to fire a job to follow up if there exists a commit after a specific date (this specific date would be an input to the job) from past release to the date the job will be fired (Assuming code freeze date) and if no release notes update the table in accordingly
Example
running ./run_releasenotes_check.sh manifests/2.0.0/opensearch-dashboards-2.0.0.yml

# OpenSearch Dashboards Commits & Release Notes info
|           Repo           |   Branch   |Commits|Release Notes|
|--------------------------|------------|-------|-------------|
|OpenSearch-Dashboards     |tags/2.0.0  |       |YES          |
|functionalTestDashboards  |main        |       |NULL         |
|queryWorkbenchDashboards  |tags/2.0.0.0|       |YES          |
|observabilityDashboards   |tags/2.0.0.0|       |YES          |
|ganttChartDashboards      |tags/2.0.0.0|       |YES          |
|reportsDashboards         |tags/2.0.0.0|       |YES          |
|indexManagementDashboards |tags/2.0.0.0|       |YES          |
|alertingDashboards        |tags/2.0.0.0|       |YES          |
|securityDashboards        |tags/2.0.0.0|       |YES          |
|anomalyDetectionDashboards|tags/2.0.0.0|       |YES          |
|notificationsDashboards   |tags/2.0.0.0|       |YES          |

Note: The above generated table is actually a markdown format, removing the code block would end up as follows

OpenSearch Dashboards Commits & Release Notes info

Repo	Branch	Commits	Release Notes
OpenSearch-Dashboards	tags/2.0.0		YES
functionalTestDashboards	main		NULL
queryWorkbenchDashboards	tags/2.0.0.0		YES
observabilityDashboards	tags/2.0.0.0		YES
ganttChartDashboards	tags/2.0.0.0		YES
reportsDashboards	tags/2.0.0.0		YES
indexManagementDashboards	tags/2.0.0.0		YES
alertingDashboards	tags/2.0.0.0		YES
securityDashboards	tags/2.0.0.0		YES
anomalyDetectionDashboards	tags/2.0.0.0		YES
notificationsDashboards	tags/2.0.0.0		YES

For commits/ bug fixes that go in during the release testing phase, we can re-fire the job to update the table, that should have new commits and again a check for release notes.
@bbarani @peterzhuamazon

[prudhvigodithi]

OpenSearch Commits(after 2022-07-26) & Release Notes info

Repo	Branch	Commits	Release Notes
OpenSearch	2.x	517b815	NO
common-utils	2.x		NO
security	main	50a94b4	YES

[prudhvigodithi]

OpenSearch Commits(after 2022-07-26) & Release Notes info

Repo Branch Commits Release Notes
OpenSearch 2.x 517b815 NO
common-utils 2.x NO
security main 50a94b4 YES

Sample test comment

[peterzhuamazon]

20220805 Runner PR:

• Add jq/yq/gh to the build docker images #2417

[opensearch-ci-bot]

Test Comment

OpenSearch CommitID(after 2022-07-26) & Release Notes info

Repo	Branch	CommitID	Release Notes
OpenSearch	2.2	4035bf7	YES
common-utils	2.x	7d53102	NO
job-scheduler	2.2	a501307	YES
security	main	f7b6fe5	YES
geospatial	2.2	a71475a	YES
k-NN	2.x	53185a0	YES

[prudhvigodithi]

Adding Commit Date to table should look as follows.

OpenSearch CommitID(after 2022-07-26) & Release Notes info

Repo	Branch	CommitID	Commit Date	Release Notes
OpenSearch	main	7dad063	2022-08-10	NO

[prudhvigodithi]

Closing this issue and the release_notes_workflow and jenkins job code is merged to main.
Thanks to @dblock for the overall review and guidance on this.
https://build.ci.opensearch.org/job/release-notes-tracker/

[prudhvigodithi]

Finalized comment from release issue 1.3.5

OpenSearch Dashboards CommitID(after 2022-07-14) & Release Notes info

Repo	Branch	CommitID	Commit Date	Release Notes
OpenSearch-Dashboards	1.3	d81a165	2022-08-23	False
functionalTestDashboards	1.3	a0267e6	2022-08-18	False
securityDashboards	1.3	7d75048	2022-08-22	True
anomalyDetectionDashboards	1.3	f9e5753	2022-08-16	False
indexManagementDashboards	1.3	cacb9d6	2022-08-18	False
queryWorkbenchDashboards	1.3	7e12bff	2022-08-17	False
reportsDashboards	1.3	f255abd	2022-08-17	False
ganttChartDashboards	1.3	a26d50d	2022-08-16	False
observabilityDashboards	1.3	05cd955	2022-08-17	False
alertingDashboards	1.3	8c6c8e5	2022-08-17	False