Automation for component release issue creation

[prudhvigodithi]

Description

Automation for component release issue creation

Create a release issue in build repo this logic is same using the action dblock/create-a-github-issue@v3.0.0. Using matrix for each repo and version creates an issue in components/plugins repo using peter-evans/create-issue-from-file@v4, the action dblock/create-a-github-issue@v3.0.0 does not support cross repo issue creation.

Using actions-cool/issues-helper@v3 to identify if an issue already exists as by default the peter-evans/create-issue-from-file@v4 does not have this logic (related open issue: peter-evans/create-issue-from-file#298).

The dblock/create-a-github-issue@v3.0.0 has the logic to avoid creation of duplicate issues (search_existing: all) but does not work in creating issues for cross repo.

Hence the combination of all works better in creating a release issue in build repo and component release issue in plugins repo.

The step Replace placeholders updates the component_release_template.md file with right versions before creating a component release issue.

Note: This creates the main release issue and component release issues but it wont update the component section markdown table of the main release issue.

Sample Testing:
Sample Run:

Sample Component Issue: prudhvigodithi/job-scheduler#23

Skipping for non major/minor version: (Logic used is to check if the last digit endsWith with .0 )

Issues Resolved

Part of:
#3349
#3676
opensearch-project/.github#167

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.

[codecov]

Codecov Report

Merging #3708 (f70bf3a) into main (142f8c3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #3708   +/-   ##
=======================================
  Coverage   91.54%   91.54%           
=======================================
  Files         182      182           
  Lines        5420     5420           
=======================================
  Hits         4962     4962           
  Misses        458      458           

[gaiksaya]

One thought is, usually when a release manager creates an issue, they get notifications when someone comments on it with any component related update. But now, since bot it creating the issues it would be difficult to get notified. Maybe we can include the name of the release manager (by tagging) in someway so that they get notified too?
It's difficult to go and track all 20+ issues to see if there is an update.

[prudhvigodithi]

One thought is, usually when a release manager creates an issue, they get notifications when someone comments on it with any component related update. But now, since bot it creating the issues it would be difficult to get notified. Maybe we can include the name of the release manager (by tagging) in someway so that they get notified too? It's difficult to go and track all 20+ issues to see if there is an update.

I agree with this point, one way is during runtime an RM can inject his token to ensure the issues are created with an RM username but again this would be a manual step, the change of workflow through this PR adds a link of main release issue (part of the build repo) to all the component release issues, having this GitHub should link the component release issues to main issue and an RM can follow up from there.

[prudhvigodithi]

@bbarani @peterzhuamazon @dblock please add your thoughts.

[dblock]

If this works it LGTM, although @gaiksaya comment is very valid.

Consider contributing the feature you need to dblock/create-a-github-issue? Or at least opening an issue?

[prudhvigodithi]

Thanks @dblock I have just opened one dblock/create-a-github-issue#71.

[prudhvigodithi]

Thanks I will merge this for now as it removes the manual effort to create releases issues across multiple repos, we can always come back and modify as required.
Thank you

[prudhvigodithi]

I dint knew GitHub has 256 hard limit. When I execute I get the following error. I have tested on my local with 4-5 of my fork repos, but when added all the release OS and OSD component repos and matrix combination of all the manifests part of the manifest folder its exceeding more than 256.
https://github.com/opensearch-project/opensearch-build/actions/runs/5557372749

[releases: .github#L1](https://github.com/opensearch-project/opensearch-build/commit/a61520274af7e878aa66a3ca489b044ecb7cdc0b#annotation_12630538500)
Strategy produced more than 256

More information: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix