Add RuntimeLogs() method for retrieving application runtime logs

[ramonskie]

Summary

Adds a platform-agnostic RuntimeLogs() API for retrieving logs from running applications after deployment succeeds. This complements the existing staging logs returned by platform.Deploy.Execute() by providing access to post-deployment application output.

This PR also refactors the log fetching logic introduced in #121 (commit 8fb0d65) by extracting a shared FetchRecentLogs() helper function, eliminating code duplication between staging failure logs and runtime logs retrieval.

Key Changes

• Add Deployment.RuntimeLogs() method - Retrieves runtime logs for both CloudFoundry and Docker platforms
• Extract cloudfoundry.FetchRecentLogs() helper - Shared log fetching logic used by both staging failures and runtime logs
• Add comprehensive tests - 37 tests pass (2 new tests for helper function)
• Update README - Documents the new RuntimeLogs() API with clear examples

API Design

The API provides clear separation between staging logs (build-time) and runtime logs:

// Staging logs (build-time) - returned from Execute()
deployment, stagingLogs, err := platform.Deploy.Execute(name, path)

// Runtime logs (post-deployment) - explicit method call
runtimeLogs, err := deployment.RuntimeLogs()

Staging Logs (Build-Time)

• Returned as 2nd parameter from platform.Deploy.Execute()
• Contains buildpack detection, compilation, and staging output
• Available even when deployment fails
• Use for testing: buildpack detection, compilation errors, build-time env vars

Runtime Logs (Post-Deployment)

• Retrieved via deployment.RuntimeLogs() method
• Contains application startup and runtime output
• Only available after successful deployment
• Use for testing: app startup, service connections, module loading, runtime config

Use Cases

This enhancement simplifies buildpack integration tests that need to verify runtime behavior:

Before (manual workaround):

var cmd *exec.Cmd
if settings.Platform == "docker" {
    cmd = exec.Command("docker", "container", "logs", deployment.Name)
} else {
    cfHome := filepath.Join(os.TempDir(), deployment.Name)
    cmd = exec.Command("cf", "logs", deployment.Name, "--recent")
    cmd.Env = append(os.Environ(), fmt.Sprintf("CF_HOME=%s", cfHome))
}
output, _ := cmd.CombinedOutput()
Expect(string(output)).To(ContainSubstring("Application started"))

After (simple API):

deployment, _, err := platform.Deploy.Execute(name, path)
runtimeLogs, err := deployment.RuntimeLogs()
Expect(runtimeLogs).To(ContainSubstring("Application started"))

Example: Testing Both Staging and Runtime

it("Compiles dependencies and connects to database", func() {
    deployment, stagingLogs, err := platform.Deploy.
        WithBuildpacks("python_buildpack").
        WithServices(map[string]Service{
            "postgres": {"uri": "postgresql://localhost:5432/testdb"},
        }).
        Execute(name, filepath.Join(fixtures, "django-app"))
    
    Expect(err).NotTo(HaveOccurred())
    
    // Verify build-time behavior
    Expect(stagingLogs.String()).To(ContainSubstring("Installing dependencies"))
    Expect(stagingLogs.String()).To(ContainSubstring("Building psycopg2"))
    
    // Verify runtime behavior
    runtimeLogs, err := deployment.RuntimeLogs()
    Expect(err).NotTo(HaveOccurred())
    Expect(runtimeLogs).To(ContainSubstring("Connected to database"))
    Expect(runtimeLogs).To(ContainSubstring("Server started on port 8080"))
})

Benefits

• ✅ Clear separation between staging logs and runtime logs
• ✅ Platform-agnostic - works identically for CloudFoundry and Docker
• ✅ DRY principle - consolidates duplicate log fetching code
• ✅ Self-documenting - explicit method names make intent clear
• ✅ No breaking changes - existing tests work without modification
• ✅ Comprehensive tests - 37 tests pass including new functionality

Improvements Over PR #121

This PR builds upon the staging failure logs work from #121 by:

1. Extracting shared logic - The cf logs --recent code is now in a reusable FetchRecentLogs() helper
2. Adding runtime logs API - Tests can now verify post-deployment behavior
3. Reducing code size - stage.go log fetching reduced from 15 lines to 5 lines
4. Adding test coverage - New tests for the shared helper function

Testing

All tests pass:

• ✅ 37 total tests (2 new tests for FetchRecentLogs())
• ✅ CloudFoundry runtime logs retrieval tested
• ✅ Docker runtime logs retrieval tested
• ✅ No regressions in existing tests

Related

• Extends Capture staging logs on failure in CF API v3 #121 (commit 8fb0d65) - staging failure logs
• Addresses common buildpack test pain point of manually fetching runtime logs

[ivanovac]

LGTM