Maintenance of multiple instances

[petersalomonsen]

Is your feature request related to a problem? Please describe. We have just launched the "Events committee" instance of DevHub, which is in its own branch without any automatic sync of updates from the main DevHub instance. Any future enhancements or fixes on DevHub will have to manually synced into the Events committee branch. This adds extra maintenance work just for the extra instance, and will not scale if adding more instances.

Describe the solution you'd like It should be possible to maintain multiple instances of the DevHub platform from one codebase that is configurable when it comes to which features that should be enabled in each instance. Updates on the main codebase should also trigger deployments to all instances. To a large extent this configurability is already there, since we are deploying separate instances for preview environments, even with separate contracts. What's missing is feature toggling, simple theming ( colors and logo ) and dedicated indexers (queryapi) for each instance.

After a meeting with @Megha-Dev-19, @Tguntenaar and @petersalomonsen we recommend using BOS-workspaces because of the structure with a folder per instance ( account name ), and we can then have separate landing pages for each instance, but reference common components from the devhub.near folder. We propose feature toggles through props or replacements as we have done until now. BOS-workspaces can be applied to the existing repository, so that we keep the references to github issues, and the history of the codebase.

### Tasks
- [ ] https://github.com/NEAR-DevHub/neardevhub-bos/issues/837
- [ ] Add infrastructurecommitte.near folder to the BOS workspace, and copy contents from infrastructure committee repostitory, also update the mapping/migration scripts to sync changes to the new BOS workspace structure (Megha)
- [ ] https://github.com/NEAR-DevHub/neardevhub-bos/issues/842
- [ ] Ensure that all instances are covered by automatic tests, and tested on every Pull Request
- [ ] Adjust deployment pipelines to deploy all instances
- [ ] Add feature toggles using input props or replacements to common used components ( e.g. Proposal, with and without RFP ) so that we can turn off features not used by for example the Event Committee instance
- [ ] Add possibility to configure simple theming (colors and logo) through props or replacements
- [ ] Add dedicated indexers ( queryapi ) per instance, but the same codebase, need replacements for supporting multiple instances

[petersalomonsen]

@ori-near consider this ticket for ensuring that we can maintain multiple instances of the DevHub platform.

[Megha-Dev-19]

@petersalomonsen how about creating a separate file (db) which contains all the static data, like logo, heading, content, css, and we can export it for each instance and use as constants in the needed widget, because I don't think we need to store this data on social-db specially related to styling I really like the feature toggle idea, that would be great considering minor differences in each instance I really like bos-workspace which allows multiple apps development with much ease

[petersalomonsen]

Sounds like a good idea. Are you thinking that we store this static assets in the git repo, or for example NEARFS/IPFS ( and just point to the URLs )?

Using bos workspace also makes sense

[Megha-Dev-19]

I don't think we can export assets from files in VM, can we? I assumed we will upload it and then use that ID.

[petersalomonsen]

I don't think we can export assets from files in VM, can we? I assumed we will upload it and then use that ID.

Yes we can upload it. NEARFS is a good option then.

[petersalomonsen]

@Megha-Dev-19 @Tguntenaar I guess we are ready to move infrastructure / events committee into this repo then.