Add RenderStatus to the Kptfile for per-function pipeline result tracking

[aravindtga]

After every kpt fn render execution, a structured renderStatus is now recorded in the root Kptfile alongside the existing Rendered condition, providing per-function pipeline result tracking.

Note

76 of the 79 changed files are E2E test fixture updates (e2e/testdata/fn-render/**/.expected/diff.patch). The core implementation changes are in 3 files.

What

• Add a renderStatus field to status in the root Kptfile after render
• Track per-function results for both mutation and validation pipeline steps
• Each PipelineStepResult captures: function name/image/exec, exit code, stderr, structured results, and error-only results
• On failure: an errorSummary aggregates which steps failed and why

Fixes: #4390

Success case:

status:
  conditions:
    - type: Rendered
      status: "True"
      reason: renderSucceeded
  renderStatus:
    mutationSteps:
      - image: gcr.io/kpt-fn/set-namespace:v0.4.5
        exitCode: 0
    validationSteps:
      - image: gcr.io/kpt-fn/gatekeeper:v0.2.1
        exitCode: 0

Failure case:

status:
  conditions:
    - type: Rendered
      status: "False"
      reason: renderFailed
      message: "pipeline failed"
  renderStatus:
    mutationSteps:
      - image: set-namespace:v1
        exitCode: 0
    validationSteps:
      - image: gatekeeper:latest
        exitCode: 1
        stderr: "validation failed"
    errorSummary: "gatekeeper:latest: exit code 1"

Behaviour

• In-place render (kpt fn render): renderStatus is written to the Kptfile
• Out-of-place / stdout / unwrap mode (kpt fn render -o <dir|stdout|unwrap>): renderStatus is not written since there is no on-disk package to update

Tests

• 76 E2E expected diff patches updated to reflect the new renderStatus field in Kptfile output

[netlify]

✅ Deploy Preview for kptdocs ready!

Name	Link
🔨 Latest commit	b30219c
🔍 Latest deploy log	https://app.netlify.com/projects/kptdocs/deploys/69c171ad6449dd0008161a04
😎 Deploy Preview	https://deploy-preview-4437--kptdocs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Copilot]

Pull request overview

This PR extends the root Kptfile status to include a structured renderStatus after kpt fn render, enabling per-function pipeline step result tracking (mutation + validation) and updating E2E fixtures accordingly.

Changes:

• Add status.renderStatus (mutationSteps/validationSteps/errorSummary) to the Kptfile v1 API types.
• Track and persist per-step execution details during render, and write them into the root Kptfile for in-place renders.
• Make E2E diff comparisons more resilient by allowing regex-based stripping/normalization of diff output.

Reviewed changes

Copilot reviewed 137 out of 138 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/api/kptfile/v1/types.go	Adds Status.RenderStatus and supporting status/result schema types.
internal/util/render/executor.go	Captures per-function step results during render and writes renderStatus into the root Kptfile on in-place renders.
internal/util/render/executor_test.go	Adds unit tests for renderStatus building and result capture/conversion.
pkg/test/runner/config.go	Adds diffStripRegEx test config knob for diff normalization.
pkg/test/runner/runner.go	Normalizes diffs (strip + header normalization) before comparing expected vs actual diffs.
e2e/testdata/fn-render/**/.expected/diff.patch (many files)	Updates expected diffs to include the new status.renderStatus output.
e2e/testdata/fn-render/**/.expected/config.yaml (some files)	Adjusts expected configs to use diffStripRegEx (and related stderr matching changes).
e2e/testdata/fn-render/**/starlark-fn-failure.yaml (some files)	Adds fixtures to reliably force function failure for renderStatus failure-path expectations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 137 out of 138 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 137 out of 138 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 137 out of 138 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 137 out of 138 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

internal/util/render/executor.go:799

• In runMutators, several failure paths occur before mutation.Execute() (e.g., errors from GetPkgPathAnnotation, GetFileAnnotations, SetResourceIDs, SelectInput). Those currently return without appending a PipelineStepResult, so the new status.renderStatus.mutationSteps can be missing the step that was being prepared/executed when render failed. Consider recording a failure step for pl.Mutators[i] (e.g., via preExecFailureStep or a dedicated helper) before returning on these pre-exec errors so RenderStatus remains complete/diagnostic.
  internal/util/render/executor.go:855
• In runValidators, if SelectInput fails (or any other pre-run setup error happens before NewRunner/Filter), the code returns immediately without appending a PipelineStepResult to hctx.validationSteps. This can leave status.renderStatus.validationSteps incomplete on failure. Consider capturing a failure step for the current function (similar to the --allow-exec / NewRunner error paths) before returning.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.