Repository navigation
Set up CI to run the test suite #2
Description
Problem
The repo has no CI. gh pr checks on #1 reported "no checks reported on the 'feat/match-tsx-servers' branch", so the ship/review workflow's "CI green" step is vacuous — tests/test-cli.sh only runs when someone remembers to run it locally.
This matters more than usual here: the whole tool is regex-driven process matching, where a subtly wrong pattern silently either misses dev servers or, worse, kills unrelated processes. #1 shipped both a false-negative fix and a false-positive fix; neither would have been caught by anything automated.
Proposal
A GitHub Actions workflow on push and pull_request that runs:
-
bash tests/test-cli.sh -
shellcheck kill-dev-servers.sh install.sh tests/test-cli.sh— the script is nontrivial bash with arrays, associative arrays, and regex; shellcheck earns its keep -
bash -nsyntax check on the same files
Notes
- The suite stubs
ss,lsof,ps, andreadlinkviaPATH, and spawns real background PIDs so the script's/proclookups see live processes. It needs a Linux runner with/proc—ubuntu-latestis fine, macOS is not (and is already listed as unsupported in the README). - Worth considering a matrix over bash versions. README claims "Bash 4 or newer";
ubuntu-latestships bash 5, so the bash 4 claim is currently untested. - Installer coverage is a separate question.
install.shwrites to global agent instruction files, so any CI exercise of it must setKDS_SKIP_AGENT_INSTRUCTIONS=1.
Activity
zanellig commentedon Sep 3, 2026
Done in #4 (merged).
.github/workflows/ci.ymlruns onpull_requestand on pushes tomain(push is scoped tomainso PR branches get one run, not two), onubuntu-latestsince the suite spawns real PIDs and reads/proc:bash -nover the three scripts, one file per invocation —bash -nonly reads its first file argument and treats the rest as positional parameters, so the obvious one-liner would have checked onlykill-dev-servers.shshellcheck kill-dev-servers.sh install.sh tests/test-cli.sh(preinstalled on the runner)bash tests/test-cli.shThe gate paid for itself on its first run. It caught a locale-dependent bug: listener discovery sorted bindings under the ambient locale, so a process bound to both
*:3002and127.0.0.1:3002rendered them in one order underen_US.UTF-8and the reverse under the runner'sC.UTF-8. Fixed at the source — discovery now sorts withLC_ALL=C— rather than by loosening the assertion. Codex independently flagged the same thing as P1.Enabling shellcheck also required fixing SC2295 (unquoted
${BASH_REMATCH[1]}inside a${var#pattern}pattern), SC2004, SC2190 (an associativetarget_indiceslocal colliding with the top-level index array, nowselected_indices), SC2086 in the tests, and a duplicated shebang line.Not done, both flagged in the PR:
psand/proc— thebash:4.ximages are BusyBox/Alpine, which the README already lists as unsupported — so it would mean building bash from source in CI. The README's "Bash 4 or newer" claim remains untested; worth a separate issue if the claim matters.