Research and Plan usage of Modulesync

[tobru]

As the number of components will grow, we need a way to keep the plumbing in sync over all Project Syn maintained Commodore Components.

Have a look at https://github.com/voxpupuli/modulesync, research for alternatives and figure out how we can use it for keeping plumbing configuration in syn.

This goes hand in hand with the Cookiecutter templates which also need to be kept in sync. Which one will be the main template?

[simu]

This goes hand in hand with the Cookiecutter templates which also need to be kept in sync. Which one will be the main template?

Whichever is easier to make the main template. Intuitively I'd say the modulesync template, and have it synced to the cookiecutter template as well as all components

[ccremer]

With https://github.com/projectsyn/modulesync-control we have now a template/control repository up. All it needs are more components to be added.

For each new component we probably will have to extend the existing template.
We have to carefully evaluate if a component brings plumbing that could be templatified in the control repo or whether they should be kept standalone.
I propose to add the special cases one by one so that we get a broad experience with modulesync before we roll it out over all components.

I know of the following "special" cases (special as they do more than the default component template)

• https://github.com/projectsyn/component-espejo (does testing using Go and OPA conftest)
• https://github.com/appuio/component-openshift4-terraform/ (tests for multiple terraform modules, GH matrix build)

Do you know of more?

[corvus-ch]

The foundation has been layed and implemented. See https://github.com/projectsyn/modulesync-control.