ganache-init package releases and deployment options

[almereyda]

Is your feature request related to a problem? Please describe.

In /modules/ganache-init/ there is an NPM module that contains domain-specific logic and implements an initalisation procedure for the ganache service. Its code is tightly coupled to this Compose manifest's repository, as was its predecessor to its repository.

• https://github.com/circlesland/infrastructure/tree/master/docker-compose/local/ganache/bootstrapper

Currently this NPM package is built en passant when creating the container.

Describe the solution you'd like

From a software delivery perspective, this situation is less than ideal, because the concerns of the source and build artefacts are not cleanly separated. A separation will allow to:

• publish ganache-init as separate versioned artifacts (NPM, Dockerfile) with independent documentation
• ease individual optimisations to the build process of the NPM package
• decouple different languages and programming paradigms (declarative and imperative) in the source tree
• allow reuse of ganache-init in other environments, e.g. Kubernetes

Describe alternatives you've considered

One option is to keep everything as it is, and potentially confuse the users (here: developers) of this repository with the scopes and domains of the individual parts. Then we also don't need to invest effort into maintaining a stable and auditable software supply chain.

An alternative can be to build the release artifacts from this "monorepo" and continue to release them, tightly coupling the code to its desired runtime environment, and as such loosely coupling build artefacts to the manifests. The purposes and scopes of the components in this repository remain then to be discovered individually.

As a third option, we could at least add a README to https://github.com/CirclesUBI/land-local/tree/dev/modules/ganache-init so that the package is self-contained and documented.

Additional context

Similar concerns might account for some of the other *-init containers here as well, namely:

• api-db-init
• indexer-db-init