Auto create release version branch from .x branch on start of release cycle process

[bbarani]

Is your feature request related to a problem? Please describe

We currently wait for individual repo managers to create the release branch before switching the build manifest to point to appropriate release branch for building a release candidate corresponding to specific OpenSearch version.

Acceptance criteria:

1. Add a workflow to create a new branch if doesn't exist.
2. Run the workflow from source branch to target branch when required.
3. Get the repo list from the Input Manifest/ Build Manifest and create the release branch the repos in the list.

Describe the solution you'd like

Implement an automated workflow to create the release branch from .x branch for corresponding OpenSearch and OpenSearch dashboards release version branch on beginning of release process.

Describe alternatives you've considered

Manually creating the release branch from .x branch.

Additional context

No response

[gaiksaya]

One of the major concern with this is even though we cut major.minor branch from major.x branch, who approves the changes that are going in?

Considering worst case scenario if a feature was pushed to next release or was intended for future minor release (example: 2.13.0 with 2.10.0 going on) how would we cherry-pick or decide what commits go in the 2.10 branch?

Are we okay with this edge case and add a check point in our component release issue to verify the release branch has expected changes aimed for ongoing release?

[bbarani]

@gaiksaya We need to get inputs from all teams participating in a release before we finalize this process. Creating branch automatically from .x has its own advantages and dis-advantages based on the usage of .x branch by corresponding teams. Lets use this issue is to discuss, brainstorm and analyze the feasibility of automating the release branch creation process.

[prudhvigodithi]

We can have on demand workflow that can be kicked off by a release manager after the code cut off date, the workflow will auto cut the release branch (a logic that can auto detect from <VERSION>.x to actual RELEASE_VERSION 2.x-2.12.0) for all the repos part of the input manifest. Along with creation of branch it should also update the release specific input manifests ref to use that new release branch and raise a PR to get it merged to main branch of the build repo, here is a sample manual PR raised which can be automated with the same workflow.
Thank you

[prudhvigodithi]

The Jenkins job should have the following flow.

• An input as manifests (a comma separated manifests for both OS and OSD), sourceBranch, taretBranch`.
• Identify the repos from the release specific input manifest (as a fallback a release manager can use previous release manifest) coming from the above manifests parameter .
• Git clone with a repo write access user git clone https://<PAT>@github.com/username/repo.git.
• Check if the release branch exists.
• Skip the repo if the branch exists.
• If no branch, create a branch and push to repo.
• Re-run the workflow when the new components (new plugins onboarded) added to the release input manifest.

[Divyaasm]

Closed via #4520