Allow defining service groups where cross cutting configuration can be applied

[davidfowl]

If I want to apply environment variables to a set of services, it should be possible to configure them in a group where those get applied. e.g.

Today

var builder = DistributedApplication.CreateBuilder();

builder.AddProject<P1>()
       .WithEnvironment("shared", "shared value")
       .WithEnvironment("unique", "1") ;

builder.AddProject<P2>()
       .WithEnvironment("shared", "shared value")
       .WithEnvironment("unique", "2") ;


builder.AddProject<P3>()
       .WithEnvironment("shared", "shared value")
       .WithEnvironment("unique", "3") ;

builder.Build().Run();

After

var builder = DistributedApplication.CreateBuilder();

var group = builder.CreateGroup();

group.WithEnvironment("shared", "shared value");

group.AddProject<P1>()
     .WithEnvironment("unique", "1") ;

group.AddProject<P2>()
     .WithEnvironment("unique", "2") ;

group.AddProject<P3>()
     .WithEnvironment("unique", "3") ;

builder.Build().Run();

[mitchdenny]

Do you want this in GA, I'm assuming this is post GA now?

[KennethHoff]

Most of my services require access to an internal service, and currently I've just repeated "WithRefeference()". This sounds like it could reduce needless boilerplate, and would be inline with how minimal APIs function in aspnetcore.

That said, I have another proposition. How about being able to group annotations together.

var internalService = builder.AddProject<[...];
var applicationInsights = builder.[...];

var backendStuff = builder.CreateComposable(internalService, applicationInsights);

var backendOne = builder.Add[...]
    .WithReference(backendStuff);

// The former is equivalent to: 
var backendOne = builder.Add[...]
    .WithReference(applicationInsights)
    .WithReference(internalService);

This would solve the problem, but would also allow resources to be apart of multiple "groups", which the actual group proposal wouldn't really