Extend current health check annotation and add gRPC health check

[Dona278]

Since we can customize publish output (e.g. kubernetes) may be useful to identify the kind of the health check and provide additional data.

Example of annotations

internal enum EndpointHealthCheckKind
{
    Liveness,
    Readiness,
}

internal abstract class EndpointHealthCheckAnnotation(string key, string endpointName, EndpointHealthCheckKind kind) : HealthCheckAnnotation(key)
{
    /// <summary>
    /// Type of the health check.
    /// </summary>
    public EndpointHealthCheckKind Kind { get; } = kind;

    /// <summary>
    /// Name of the endpoint to use for health check.
    /// </summary>
    public string EndpointName { get; } = endpointName;

    /// <summary>
    /// Delay in seconds before kubelet performing the first probe.
    /// </summary>
    public int InitialDelaySeconds { get; set; }
}

// Identify a "gRPC" health check annotation
internal class GrpcHealthCheckAnnotation(string key, string endpointName, EndpointHealthCheckKind kind)
    : EndpointHealthCheckAnnotation(key, endpointName, kind)
{
}

// Identify a "http" health check annotation
internal class HttpHealthCheckAnnotation(string key, string endpointName, EndpointHealthCheckKind kind, string path)
    : EndpointHealthCheckAnnotation(key, endpointName, kind)
{
    /// <summary>
    /// Path to use for health check.
    /// </summary>
    public string Path { get; } = path;
}

In this way we can store information that are missing in the current Health Check Annotation.

Example of how to use in manifest generation (I know that manifest will be deprecated :D, is only for example)

/// <summary>
/// Write probes data of the provided <paramref name="resource"/> to the manifest.
/// </summary>
public static void WriteProbes(this ManifestPublishingContext context, ProjectResource resource)
{
    // Check for endpoint health check annotation
    if (resource.TryGetAnnotationsOfType<EndpointHealthCheckAnnotation>(out var endpointHealthCheckAnnotations))
    {
        // Write probes
        context.Writer.WriteStartArray("probes");
        foreach (var endpointHealthCheckAnnotation in endpointHealthCheckAnnotations)
        {
            string kind = endpointHealthCheckAnnotation.Kind.ToString().ToLowerInvariant();

            context.Writer.WriteStartObject();
            context.Writer.WriteString("kind", kind);
            if (endpointHealthCheckAnnotation is GrpcHealthCheckAnnotation)
            {
                context.Writer.WriteString("type", "grpc");
                // Use "kind" as "service" because allowed values are the same
                context.Writer.WriteString("service", kind);
            }
            else if (endpointHealthCheckAnnotation is HttpHealthCheckAnnotation httpHealthCheckAnnotation)
            {
                context.Writer.WriteString("type", "http");
                context.Writer.WriteString("path", httpHealthCheckAnnotation.Path);
            }

            if (endpointHealthCheckAnnotation.InitialDelaySeconds > 0)
            {
                context.Writer.WriteNumber("initialDelaySeconds", endpointHealthCheckAnnotation.InitialDelaySeconds);
            }

            context.Writer.WriteString("binding", endpointHealthCheckAnnotation.EndpointName);
            context.Writer.WriteEndObject();
        }
        context.Writer.WriteEndArray();
    }
}

Some changes have to be done in current WithHttpHealthCheck and a new WithGrpcHealthCheck will be added (works in the same way but use a grpc health check from Grpc.HealthCheck nuget package).
If it would be reasonable I can contribute with PR (so I can remove custom impl in our codebase yeah)

[davidfowl]

See #890

[Dona278]

I saw, but is 1y old and I hoped for a different answer.
However the issue still open but without update and the PR created was closed and never merged, so in conclusion: no plan for that at this moment and no idea?

[davidfowl]

It needs to be re-evaluated given the changes made to aspire. Move this proposal to the issue and we can come up with a design that is relevant given the changes. What you have above is a fine start but we need to understand how it impacts docker compose, k8s, azure container apps and app service. The manifest doesn;t matter much as we've moved away from that approach and don't plan to evolve it much.

Those 4 platforms should be enough of a litmus test to extract some common format.