We should add the ability for people to tag microservices with one or more specific tags.
When deploying, we should allow people to ignore all microservices with a particular tag OR only include services with a particular tag.
The use cases for this are:
[Internal] We can keep one Tag per-sample-project, only ever publishing the microservices needed for that sample.
[Game-Maker] Game-makers might want to have a set of services that are meant to be only ever published to their dev-realms (for game-specific tooling built on SAMS).
Design:
We add a <BeamServiceGroup>BEAMPROJ_HathoraDemo,HelloEveryone</BeamServiceGroup> as an optional property we fetch from csproj files.
As part of the implicit manifest construction, we group these into a Dictionary<string, string[]> where the key is each differently found key: BEAMPROJ_HathoraDemo, etc... Dependency chains need to be resolved as part of this.
During deployment, disable services based on ignore/include tags but still publish all of them.
Remember, BeamServiceGroup can have multiple values, comma-separated, such that common services can be part of multiple groups.
Microservice Tag Filtering
We should add the ability for people to tag microservices with one or more specific tags.
When deploying, we should allow people to ignore all microservices with a particular tag OR only include services with a particular tag.
The use cases for this are:
Design:
<BeamServiceGroup>BEAMPROJ_HathoraDemo,HelloEveryone</BeamServiceGroup>as an optional property we fetch fromcsprojfiles.Dictionary<string, string[]>where the key is each differently found key:BEAMPROJ_HathoraDemo, etc... Dependency chains need to be resolved as part of this.Remember,
BeamServiceGroupcan have multiple values, comma-separated, such that common services can be part of multiple groups.group specification is an OR operation.