chore: replace stale node20 actions with inline shell + npx wait-on

[barnabasbusa]

Summary

Stacked on #10. Drops the 3 remaining transitive node20 actions that have no node24 release upstream. After this and #10, the action's transitive node deps are entirely on node24 (or have no node runtime at all).

Why not just keep waiting for upstream?

I checked. None of these are getting a node24 release any time soon:

• JarvusInnovations/background-action — open issues #206, #207, #208 all asking for node24, no response. Last commit to upstream was 2024-04. The two active forks (runlevel5/background-action, riderx/background-action) are still on node20 too — they just sit there.
• tale/kubectl-action — last release 2024-02, no maintenance activity.
• DamianReeves/write-file-action — last release 2024-02, no maintenance activity.

I also looked at iFaxity/wait-on-action and step-security/wait-on-action as drop-in replacements for background-action's wait-on logic — both still on node20.

What this PR does

Was	Now
tale/kubectl-action (sets KUBECONFIG from base64)	Inline: printf '%s' "$KUBE_CONFIG_B64" | base64 -d > $HOME/.kube/config. kubectl is pre-installed on ubuntu-latest. Input passed via env: so it can't be shell-injected.
DamianReeves/write-file-action (writes log_collector.sh)	Inline cat > file <<'SCRIPT_EOF' heredoc. GitHub still expands ${{ }} inside the heredoc body, so substitutions are unchanged; quoted heredoc keeps bash from expanding the script's own $vars.
JarvusInnovations/background-action (×2: kurtosis gateway + log collector)	nohup ... & + disown + npx --yes wait-on@8.0.1.

Why npx wait-on instead of timeout 60 shell loop

You called this out — fair point. Plain timeout 60 bash -c 'until nc -z …; do sleep 1; done' is a primitive replacement and loses the polish of background-action.

jeffbski/wait-on (the npm package, wait-on@8.0.1 released 2025-01) is exactly what JarvusInnovations/background-action wraps internally. It's actively maintained, version-pinned, and gives us real semantics:

• tcp:/file:/http:/https:/socket: probes
• configurable --timeout, --interval, --delay
• --verbose for diagnostic output
• proper exit codes, retries, exponential backoff

Plus on failure we cat the captured nohup log so CI shows why the background process didn't come up — same diagnostic value as background-action's log-output-if: failure,success.

Tradeoff: npx --yes wait-on@8.0.1 downloads ~1MB on first invocation per job. Acceptable for our use case (we only hit it on the kubernetes backend path, and the kurtosis testnet boot dominates runtime anyway). Could be cached with actions/setup-node + npm ci later if we want.

Net effect

After #10 + this PR, kurtosis-assertoor-github-action has zero transitive node20 deps. Consumers can pin a new release and be done with it.

Test plan

• CI passes
• Verify on the kubernetes backend: kubectl auth works, kurtosis gateway comes up and serves on :9710, log_collector.sh is written correctly with substituted ${{ }} values, log collector runs and produces log_collect.txt
• Verify npx wait-on exit code is propagated correctly (induce a failure by pointing at a wrong port, confirm the step fails with the captured log)

🤖 Generated with Claude Code