fix: Add stdin support to kpt fn doc for KRM functions expecting input

[pmady]

Some KRM functions fail with 'kpt fn doc' because they try to parse input from stdin even when --help flag is provided, resulting in the error: 'failed to parse input bytes: expected exactly one object, got 0'

This fix provides an empty ResourceList as stdin when running containers with --help flag, allowing functions that expect input to work properly while still displaying help documentation.

Changes:

• Add -i and --stdin flags to docker run command
• Provide empty ResourceList YAML structure as stdin
• Prevents 'expected exactly one object' errors for functions like set-namespace, set-labels, etc.

Fixes #4278

[netlify]

✅ Deploy Preview for kptdocs ready!

Name	Link
🔨 Latest commit	2e299fe
🔍 Latest deploy log	https://app.netlify.com/projects/kptdocs/deploys/6984d333ec20e300085811f0
😎 Deploy Preview	https://deploy-preview-4352--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.

[efiacor]

Hi @pmady ,
Thanks for your contribution.
Should we not try to address the underlying failure on the relevant krm functions.
The list of failing functions (that need a fix) is probably quite a bit smaller as we not longer support some of them.
ie. set-gcp-resource-ids
#4278

[pmady]

Hi @efiacor, thanks for the feedback!

You raise a valid point. I considered both approaches:

Option 1: Fix individual KRM functions (your suggestion)

• Pros: Addresses the root cause in each function
• Cons: Requires changes across multiple function repositories/images, and each function maintainer would need to update their code to handle --help without requiring stdin

Option 2: Fix in kpt fn doc (this PR)

• Pros: Single fix that works for all functions (current and future), backward-compatible, no changes needed in individual function repositories
• Cons: Slightly masks the underlying behavior of functions that don't handle --help gracefully

I went with Option 2 because:

• It provides immediate relief for users hitting this issue
• It's a common pattern - many CLI tools provide empty/minimal input when invoking help
• It doesn't break any existing functionality
• Future KRM functions automatically benefit without needing to implement special --help handling

That said, I'm happy to close this PR if the team prefers fixing the individual functions instead. Let me know which approach you'd like to proceed with!

[efiacor]

Hi @efiacor, thanks for the feedback!

You raise a valid point. I considered both approaches:

Option 1: Fix individual KRM functions (your suggestion)

* Pros: Addresses the root cause in each function

* Cons: Requires changes across multiple function repositories/images, and each function maintainer would need to update their code to handle `--help` without requiring stdin

Option 2: Fix in kpt fn doc (this PR)

* Pros: Single fix that works for all functions (current and future), backward-compatible, no changes needed in individual function repositories

* Cons: Slightly masks the underlying behavior of functions that don't handle `--help` gracefully

I went with Option 2 because:

* It provides immediate relief for users hitting this issue

* It's a common pattern - many CLI tools provide empty/minimal input when invoking help

* It doesn't break any existing functionality

* Future KRM functions automatically benefit without needing to implement special `--help` handling

That said, I'm happy to close this PR if the team prefers fixing the individual functions instead. Let me know which approach you'd like to proceed with!

Hey,
Thanks for the clarification.
I'm ok with going ahead with this, but we should prob try to capture the functions that remain to be fixed properly.
This is the "official" list of supported functions. I think a lot of the broken ones listed previously have been deprecated/unsupported.
Could we create an issue to track those changes?

[pmady]

@efiacor I've created a tracking issue as requested: #4374

Could we proceed with approving this PR?

[efiacor]

@efiacor I've created a tracking issue as requested: #4374

Could we proceed with approving this PR?

Thanks for creating the tracking issue.
Just a few test failing in this PR to address.

[pmady]

@efiacor all builds are passing now.