Allow users to define what endpoints are selected as ASPNETCORE_URLS, HTTP/HTTPS_PORTS and Kestrel endpoints

[davidfowl]

When defining endpoints on project resources, we have some default heuristics for expressing which of these endpoints are included in ASPNETCORE_URLS and which ones are included at publish time for HTTP/HTTPS_PORTS or if kestrel endpoints are defined, a way to use those.

We'd like to add some methods to allow overriding how these get included as an override in case you need to tweak the behavior. The ultimate escape hatch is setting the environment variable yourself as we don't override what users set, but maybe a more explicit way to configure set it would make sense.

This will be turned into an API proposal once we figure out the pattern.

[davidebbo]

Ok, so there are three main env variable injection scenarios:

1. At runtime, we build ASPNETCORE_URLS (but exclude Kestrel endpoints from this)
2. At Publish time, for non-Kestrel endpoints, we build HTTP/HTTPS_PORTS
3. At Publish time, for Kestrel endpoints, we inject config system override env, e.g. Kestrel__Endpoints__foo__Url

So here is a first crack:

        var project = builder.AddProject<TestProject>("proj")
            // Some `WithEndpoint` here, and/or endpoints coming from Kestrel
            .SkipEnvironmentInjectionForEndpoint("foo");

This would cause the foo endpoint not to participate in any of the above three environment injection paths. I don't think we need the granularity of saying "I want ASPNETCORE_URLS at runtime but not HTTPS_PORTS at Publish time", hence the suggestion to couple all those things.

@davidfowl Is that more or less what you had in mind?

[davidfowl]

I like the idea but should we do named based or filter based (a callback that determines what endpoints to include)?

[davidebbo]

Agreed that a callback pattern makes sense.

Additional thoughts:

• EndpointReference should have some sort of Source field that indicates where it came from, e.g. Kestrel vs Automatic vs User
• Beyond disabling magic env injection, it would be good to have a way to get rid of endpoints.

Putting it all together (naming is shaky, so focus on concept first):

public static IResourceBuilder<ProjectResource> FilterEndpoints(
    this IResourceBuilder<ProjectResource> builder, Func<EndpointReference, EndpointFilterState> filter);

public enum EndpointFilterState
{
    Keep,
    KeepWithoutVarsInjection,
    Discard
}

public enum EndpointSource
{
    Automatic,
    KestrelConfiguration,
    UserDefined
}

var project = builder.AddProject<TestProject>("proj")
    .WithHttpEndpoint()
    .FilterEndpoints(e => {
        if (e.EndpointName == "hp1")
        {
            return EndpointFilterState.KeepWithoutVarsInjection;
        }
        else if (e.Source == EndpointSource.KestrelConfiguration)
        {
            return EndpointFilterState.Discard;
        }
        return EndpointFilterState.Keep;
    })

[davidebbo]

Alternative is to not return values from the callback, and make methods available to do affect the behavior, e.g.

    .ConfigureEndpoints(e => {
        if (e.EndpointName == "hp1")
        {
            e.SkipEnvironmentInjection();
        }
        else if (e.Source == EndpointSource.KestrelConfiguration)
        {
            e.Discard();
        }
    });

But then these methods could be called at any time on any endpoint, which has its challenges. I suppose we could pass a special object that hosts those methods instead of them being directly on EndpointReference.

Kind of thinking aloud here :)

[davidfowl]

We want to keep endpoints references decoupled from how the project chooses to use them (synthetic or not), that's why I prefer a model that sets decides what endpoints to include and for what purpose.

Beyond disabling magic env injection, it would be good to have a way to get rid of endpoints.

This should be available generally on all resources. @mitchdenny we can't do this today easily.

[davidebbo]

Ok, so to summarize, there are 3 things:

1. Ability to control which endpoints get injected as env variable. That's the core of this issue.
2. Some kind of Source property on endpoints so users can make category based decisions (e.g. do something only to endpoints coming from Kestrel). This is additive and could be done separately.
3. Ability to easily remove endpoints: that needs to apply to all resources, so let's keep it separate (should open new issue)

So focusing solely on 1. and tweaking the original proposal to be filter based, something like:

public static IResourceBuilder<ProjectResource> SkipEnvironmentInjectionForEndpoints(
    this IResourceBuilder<ProjectResource> builder, Func<EndpointReference, bool> filter)


var project = builder.AddProject<TestProject>("proj")
    .WithXxx()
    .SkipEnvironmentInjectionForEndpoints(e =>
    {
        return e.EndpointName == "hp1";
    })

Yeah, the name is ugly, and I'm open to suggestions.

[davidfowl]

public static IResourceBuilder<ProjectResource> BindHttpEndpoints(
    this IResourceBuilder<ProjectResource> builder, Func<EndpointReference, bool> includeFilter);

public static IResourceBuilder<ProjectResource> WithEndpointsInEnvironment(
    this IResourceBuilder<ProjectResource> builder, Func<EndpointReference, bool> includeFilter);

public static IResourceBuilder<ProjectResource> WithAspNetCoreUrls(
    this IResourceBuilder<ProjectResource> builder, Func<EndpointReference, bool> includeFilter);

var project = builder.AddProject<TestProject>("proj")
    .WithReference(cache)
    .BindHttpEndpoints(e =>
    {
        return e.EndpointName == "hp1";
    });

[davidebbo]

I see, so you're reversing the semantics from my Skip method.

My preference among those would be WithEndpointsInEnvironment. BindHttpEndpoints feels a little vague, and I think the name needs to include the word Endpoints, making WithAspNetCoreUrls not ideal.

But anyway, the important part is to agree on the pattern so I can look at implementing. We can always tweak the name a bit later.

[mitchdenny]

Why do we need another method, can't we make this a property on the endpoint itself and set it via the WithEndpoint("name", Action<...> ...) callback?