Bundle operator related repositories into a single repo #29

The problem

Currently there is a single repository for each individual operator. In addition it is planned to have a separate repo with integration tests for each operator. This make a total of of nineteen repositories.

Several problems arise from this:

• A change to operator framework might trigger 18 PRs (in the worst case)
• Refactoring is slow and error prone.
• It's hard to keep up to date with changes and transfer knowledge from one operator to another.
• It's time consuming to keep dependencies and GitHub workflows consistent.

Articles on advantages and disadvantages of monorepos:

• https://www.happycoders.eu/java/monorepos-advantages-disadvantages/

Proposed solution

Bundle the repos mentioned into a single one.

This section addresses the following questions:

• Is the Git Workflow easily possible with a monorepo ?
• How will CI work ?
• How can the monorepo be split again in the future ?
• How to name the monorepo ?

Git Workflow

Git Workflow might not be (easily) possible in such a Repository with multiple artifact releases.

One simple solution would be if all artifacts share the same release version.

CI

GitHub Workflows can be triggered by changes in subfolders: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths

How to manually trigger a CI/CD job ?

In case a Workflow is not triggered or fails (for reasons that have nothing to do with the actual changes) how to manually trigger the CI/CD jobs just for the affected components (subfolders) ?

Probably the easiest is to make a dummy push in the affected subfolders.

Splitting strategies

There is a fair chance that the resulting repository might be split again in the future into multiple repositories. In this case, the git commit history should be preserved.

Following strategies are available:

Strategy 1: Keep the entire history

This is the obvious and easy one. Here we clone a new repo, remove all unwanted (sub)folders and move the contents of the remaining ones to the top level.

Example:

git clone https://github.com/ao/your_repo.git
cd your_repo
git rm -rf <unwanted-folders>
git mv <remaining-folder-contents> .
git commit -am 'Split <contents> from old monorepo'
git remote set-url origin https://github.com/ao/your_new_sub_repo.git
git push -u origin

Strategy 2: Keep the history of a specific subdirectory (operator, tests or something else)

See: https://ao.ms/how-to-split-a-subdirectory-to-a-new-git-repository-and-keep-the-history/

The git filter-branch command is used.

Here is the gist of it:

git clone https://github.com/ao/your_repo.git
cd your_repo
git checkout your_branch_name
git filter-branch --prune-empty --subdirectory-filter relative/path/to/subdirectory your_current_branch_name
git remote set-url origin https://github.com/ao/your_new_sub_repo.git
git push -u origin your_current_branch_name

Name

Proposed names of the new repo:

• operator-bundle
• stackable-operators
• smooth-operator