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	13ed78f
🔍 Latest deploy log	https://app.netlify.com/projects/kptdocs/deploys/69bc535e86ad3c0007d37837
😎 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]

When fnChain returns an error, runMutators records an executionErrorStep using the entire pl.Mutators list, but executionErrorStep always uses the first function in the list. This can misattribute the failure to the wrong mutator (e.g. if the 2nd+ function fails image resolution or is an exec step disallowed by --allow-exec). Consider changing fnChain to return which Function failed (or returning a partial slice + failing index) so the RenderStatus step result accurately identifies the failing mutator.

[Copilot]

normalizeDiff uses regexp.MustCompile(stripRegEx), which will panic (and crash the whole test run) if a test config provides an invalid regex. Consider compiling with regexp.Compile and returning an error that compareResult can surface (similar to compareOutput’s StdErrRegEx handling), rather than panicking.