Add telemetry-enabled input to disable telemetry in single step

[Copilot]

Disabling telemetry currently requires a separate workflow step to run testkube disable telemetry after the action completes, wasting runner CPU time.

Changes

• action.yml: Add telemetry-enabled input (defaults to "true")
• src/index.ts: Execute testkube disable telemetry after context setup when telemetry-enabled: false
• README.md: Document new input and add usage example

Usage

- uses: kubeshop/setup-testkube@v1
  with:
    namespace: default
    telemetry-enabled: false

Backward compatible - telemetry remains enabled by default.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Feature Request: Disable Telemetry Option</issue_title>
<issue_description>Afaik disabling telemetry currently requires two steps in GitHub actions, e.g.:

steps:
  - uses: kubeshop/setup-testkube@v1
     with:
       namespace: default
       version: 2.1.48

    - run: testkube disable telemetry

This requires unnecessary runner CPU time. Adding an option would simplify this process:

steps:
  - uses: kubeshop/setup-testkube@v1
     with:
       namespace: default
       version: 2.1.48
       telemetry-enabled: false

The default could be true for backward compatibility.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Feature Request: Disable Telemetry Option #13

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[olensmar]

@greptile

[greptile-apps]

Greptile Summary

This PR adds a telemetry-enabled input to the action, letting users disable Testkube telemetry in a single step instead of adding a separate run: testkube disable telemetry step. The implementation is clean, backward-compatible (defaults to "true"), and follows the standard GitHub Actions boolean-input convention (!== "false").

As a positive side effect, the refactoring of the final spawnSync call also fixes a latent bug in the original set context error-handling: the old status || 0 would silently exit with code 0 when spawnSync returned a null status (i.e. the child process was killed by a signal), whereas the new !== 0 guard correctly exits with code 1 in that case.

No blocking issues found.

Confidence Score: 5/5

• This PR is safe to merge — minimal, well-scoped change with no logic errors or security concerns.
• The feature is a straightforward boolean gate around an existing CLI call. Input parsing follows the idiomatic GitHub Actions pattern, the default preserves backward compatibility, the compiled dist matches the source, and the refactoring incidentally improves error handling for the pre-existing set context call.
• No files require special attention.

Important Files Changed

Filename	Overview
src/index.ts	Adds telemetryEnabled boolean param, correctly parsed as !== "false" (standard Actions pattern); runs testkube disable telemetry after context setup. As a side effect, the contextResult error-handling is improved — the original `
action.yml	Adds telemetry-enabled input with correct default: "true" and required: false. Clean and backward-compatible.
dist/index.js	Compiled bundle matches src/index.ts changes faithfully — same telemetryEnabled parsing, same contextResult early-exit, same disable-telemetry block.
README.md	Documents new telemetry-enabled input in the table and adds a usage example. Consistent with existing docs style.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Action starts] --> B[Parse inputs\nincl. telemetry-enabled]
    B --> C[Install Testkube CLI]
    C --> D[testkube set context\n...contextArgs...]
    D --> E{contextResult.status == 0?}
    E -- No --> F[process.exit status or 1]
    E -- Yes --> G{telemetryEnabled == false?}
    G -- No --> H[process.exit 0]
    G -- Yes --> I[testkube disable telemetry]
    I --> J{telemetryResult.status == 0?}
    J -- No --> K[process.exit status or 1]
    J -- Yes --> H

Loading

_{Last reviewed commit: "Add telemetry-enable..."}