New automation setup: one repo with multiple models of one type only

[vikas-agarwal76]

Issue description / feature objectives

We need a new repo organization for agile authoring. Currently we have separate repos for each different model authoring - catalogs, profiles, etc. and only one model for that type in a repo so that it can be versioned.

We now need to allow authoring of multiple models for one type in a repo and each needs to be have separate authoring, approval and versioning. For example we may have one repo for comp. defs. which may have more than one comp def.s say compDef1, compdef2, and so on. We need to allow each of then to be separately developed/authored, approved, versioned.

As discussed with @enikonovad the way to do this is to have one main branch which will have only release versions of each of the comp defs. (no develop or un-released content) like compef1_v1.0, compef1_v1.1, compef2_v1.0, compef2_v1.1 and so on. Next, we will have one separate dev branch for each different compdef like dev_compdef1, dev_compdef2 and so on. All the developemnt, markdown editing, approval, etc. will have in the respective dev branches only. On merging of a dev branch to main, only that specific compdef would be versioned and released in main.

For this we will need versions to be specified as part of the commit/PR for making a release of the compdef. As part of automation, we should pick the version from the commit/PR message and use that for versioning.

We also need to have separate appproval list for separate dev branches as approvers for different content may be different. Also, it will be good to create a changelog file for each different compdef such as compdef1, compdef2, ... This changelog file should be mreged into main branch whenever any model is relased.

Caveats / Assumptions

The assumption is that only one model type - either catalog, profile, cd, SSP, will be edited in one repo.

We can later generalize it to support multiple different model types, each with one or models. This will require creating dev branches for each content that needs to be edited such as catalog1, catalog2, profile1, profile2, cd1, cd2, and so on.

Completion Criteria

The automation for this needs to be first tested in compliance-trestle-testing organization and then replicated to production repos such as unified-component-defintions and others.