Implement HTTP Headers Support for Health Probes

[simple-container-forge]

Implementation Request

Parent Issue: #168
Base Branch: simple-forge/issue-168-support-httpheaders-in-health-tb2lry

Description

Add httpHeaders field to health probe configuration to support custom HTTP headers in readiness, liveness, and startup probes. This involves adding new types, updating data structures, modifying the probe conversion logic, and ensuring backward compatibility.

Technical Notes

• Maintain 100% backward compatibility - existing configs must work without changes
• Follow existing code patterns in pkg/clouds/k8s/types.go and pkg/clouds/pulumi/kubernetes/deployment.go
• Use omitempty JSON tags for new fields to preserve existing behavior
• Add comprehensive unit tests for header conversion logic
• Update JSON schemas for validation
• Ensure proper pointer handling with Pulumi's sdk.String()

Files/Areas

• pkg/clouds/k8s/types.go - Add HTTPHeader type and update ProbeHttpGet struct (lines ~110-113)
• pkg/clouds/pulumi/kubernetes/deployment.go - Update toProbeArgs() function to convert headers (lines ~279-314)
• docs/schemas/ - Update JSON schemas for probe configurations
• pkg/clouds/k8s/types_test.go - Add unit tests for HTTPHeader validation

Acceptance Criteria

• HTTPHeader type defined with Name and Value fields
• ProbeHttpGet struct includes optional HTTPHeaders field with omitempty tag
• toProbeArgs() function converts []HTTPHeader to corev1.HTTPHeaderArray
• Headers are properly set on HTTPGetActionArgs when specified
• All existing tests pass without modification (backward compatibility)
• Unit tests added for header conversion logic including edge cases
• Documentation includes YAML examples with httpHeaders
• JSON schemas updated to validate httpHeaders structure
• Code comments document the new fields with examples

Design Documentation

• docs/design/2026-02-26/health-probe-http-headers/design.md

Notes

Design includes detailed data model changes, Kubernetes integration approach, validation rules, testing strategy, and comprehensive examples. The implementation is additive only - no breaking changes to existing APIs.

Priority: medium

---

This issue was automatically created by the Multi-Role Orchestration system.

[simple-container-forge]

🤖 Simple Forge Processing

I'm analyzing your request and will start working on it shortly.

📋 Issue: Implement HTTP Headers Support for Health Probes
🌿 Branch: simple-forge/issue-172-implement-http-headers-support-tb4omb

⏳ Status: Initializing workflow...

I'll update this comment with progress and results.

[simple-container-forge]

✅ Workflow Completed Successfully!

Great news! The Simple Forge has successfully processed your request.

📋 Job Details:

• Job ID: 82f1d67a-8114-4fa9-9c9d-f5d2d4430196
• Job URL: https://forge.simple-container.com/jobs/82f1d67a-8114-4fa9-9c9d-f5d2d4430196
• Branch: simple-forge/issue-168-support-httpheaders-in-health-tb2lry
• Workflow: View Results
• Completed: 2026-02-27 17:44:07 UTC

📝 Execution Summary:
I've processed the issue and made the following changes:

I'll analyze the codebase and implement the HTTP headers support for health probes. Let me start by understanding the current state of the code.

Excellent! I can see that the core implementation is already complete in the codebase. Let me verify this and check what else needs to be done:

1. ✅ HTTPHeader type is already defined in pkg/clouds/k8s/types.go:121-126 with full documentation
2. ✅ ProbeHttpGet struct already includes HTTPHeaders []HTTPHeader field at line 131
3. ✅ toProbeArgs() function already converts headers to Kubernetes format at lines 308-318 in deployment.go

The main implementation is complete! Now I need to:

1. Add unit tests
2. Create implementation documentation
3. Run formatter and tests
4. Write handoff files

Let me check if there are existing tests to understand the testing patterns:

Now let me check the types_test.go to understand the testing pattern better:

I can see that tests for HTTPHeader types already exist. Now let me check if there are tests for the toProbeArgs function:

Let me check if there are any tests specifically for probe conversion:

Now let me create tests for the probe conversion function. First, let me update the todo list and then add the tests:

Now let me create a new test file for the probe conversion function:

Now let me update the todo list and run the formatter and tests:

Now let me check if Welder is installed and run the formatter and tests:

Great, Welder is already installed. Now let me run the formatter:

The formatter ran but there's an issue with gofumpt not being found. Let me try installing it and then re-run:

Now let's run the formatter again:

Let me check the welder configuration:

Let me try running the tools task first:

Now let me try the fmt again:

I see the issue. The toProbeArgs function returns a *corev1.ProbeArgs which is the actual args struct, not the input type. The test is trying to access fields on the wrong type. Let me fix the test:

I see the issue - the tests are trying to access the struct fields, but toProbeArgs returns a *corev1.ProbeArgs which uses input types (wrappers). I need to look at how to properly test this. Let me check the actual Pulumi types:

The issue is that corev1.ProbeArgs returns pointer types for its fields. I need to update my tests to properly handle the Pulumi types. Let me rewrite the test file with proper assertions:

Now let me run the formatter again:

I see the issue. The result.HttpGet is a pointer type (HTTPGetActionPtrInput) not the actual struct. I need to check how to access the actual values. Looking at the deployment.go code, I see that toProbeArgs returns *corev1.ProbeArgs where the HttpGet field is of type *corev1.HTTPGetActionArgs. Let me check the deployment.go more carefully:

I see! The toProbeArgs returns *corev1.ProbeArgs where HttpGet is of type *corev1.HTTPGetActionArgs (not the input type). The problem is that the type is being checked before assignment. Let me look at the Pulumi types more carefully - it seems like there might be an interface issue. Let me check what the actual Pulumi types are:

I see! The HTTPGetActionArgs struct has fields of input types (like HttpHeaders HTTPHeaderArrayInput). So when I access result.HttpGet.HttpHeaders, I'm accessing the input type. Let me look at what HTTPHeaderArrayInput is:

So HTTPHeaderArray is a slice of HTTPHeaderInput. Now let me check the test access pattern - I should be able to index into the array since it's defined as []HTTPHeaderInput. Let me check HTTPHeaderInput:

I see - it's an interface. The issue is that I need to type assert to access the underlying HTTPHeaderArgs. Let me check what HTTPHeaderArgs looks like:

[Content truncated - full details available in workflow logs]

🎉 Next Steps:

• Review the changes in the Pull Request #170
• Test the implementation
• Merge the pull request when ready

Feel free to ask for any modifications or improvements!