Automate: Update the Github release issue with the right RC information.

[prudhvigodithi]

Is your feature request related to a problem? Please describe

Coming from an example RC (release candidate) information, there is lot of manual effort involved in adding/editing the comment that has the detailed information about the generated release candidate information for a specific version. This is time consuming and sometimes there are changes the URL's are not properly constructed, also the template for that comment is not standard, each release version has its own format, because of the fact that each release is done by a different release manager.

Describe the solution you'd like

Automation this process.

Have a jenkins job that can add/update the GH release issue with the right RC candidate information.

1. Input by the user: GH issue number to add a comment.
2. Input by the user: GH issue number comment unique ID, to update the comment.
3. Input by the user: RC candidate build number for both OpenSearch and OpenSearch dashboard.
4. A .MD file template that can be used and just be parsed during runtime with right RC build and version numbers.

Describe alternatives you've considered

No response

Acceptance Critera

• Generate artifacts.md on every build (only when successful) that contains all the information for testing the artifacts generated by that build.
• If the build did not generate for example, a windows artifacts, the artifacts.md should mention that this artifact was skipped.
• Information that needs to be a part of artifacts.md
  • URLs to download the artifacts from. (Avoid using latest as it is dynamic)
  • Information on how to set up test cluster using that artifact
  • With / Without security instructions
• Have an optional parameter in build workflow to post the link of above artifacts.md as a comment on the given GH issue as a comment.

[dblock]

I think you can simplify this further by having an artifacts.md file generated for every build instead of having a template to append to a GitHub issue.

Another idea is that logically what you're trying to do is "declare a build a release candidate". When that happens several activities need to be executed, including appending testing information to a GitHub issue. If a new Jenkins workflow is added I would model it accordingly.

[bbarani]

[Tirage] We will look on automating the generation of artifacts.md file for RC builds.

[gaiksaya]

Approach 1 seems to be pretty straight forward. Explaining a bit in detail below:

Let the artifacts.md file be generated for each build. Similar to https://build.ci.opensearch.org/job/distribution-build-opensearch/6234/artifact/buildInfo.yml/*view*/

The artifacts.md file will contain all the instructions to test the artifacts generated by that build including tarballs, rpms, docker, etc.
When we generate the release candidate there is nothing extraordinary that needs to be done, just post the link of the build or artifacts.md file on the release issue. We can automate this by adding a optional param in build workflow to post artifacts.md file link to given GH issue number as a comment.