gstack-pregate: .bats tests are never recognised, so lanes always fails in bats repos #3161

Activity

1. harjothkhara

   added a commit that references this issue on Oct 14, 2026

   liveness screenshot for garrytan#3161

   aa04827
2. capy-ai

   closed this as completedin 82530acon Oct 17, 2026
3. billy-armstrong

   added a commit that references this issue on Oct 17, 2026

   v1.91.117.0 fix: pregate bats lanes, WTREE_UNAVAILABLE, doctor rows, …

   ...

   82530ac
4. yolo-jared commented on Oct 17, 2026

   

   yolo-jared

   on Oct 17, 2026

   Contributor

   More actions

   +1, with a second real repo hitting this, and a test of #3177 against real bats-core.

   Repo: a private agent-config repo (shell scripts, hooks, bootstrap installers). Its tests are 14 bats files, 426 tests, on Bats 1.13.0. There are also some node --test files.

   What we see today:

   • With no .gstack/pregate.json, 290 of 361 tracked files fail lanes with PREGATE_NO_LANE.
   • The only way through is the workaround described here: map every shell and bats path to []. The pre-gate then passes without running a single bats test.
   • A whole-suite guards entry is no substitute. The suite takes 377 s, and the slowest file takes 97 s.
   • A guard that buffers its output so it can check the test count prints nothing for that long. That runs into the 300 s stall_timeout_s default added in v1.91.107.

   #3177 on real bats.

   • Both runs used the same repo commit, the same .gstack/pregate.json and Bats 1.13.0.
   • Before = gstack main at 0bf9d508, the commit fix(pregate): recognise bats test files so lanes does not fail in bats repos #3177 is based on. After = fix(pregate): recognise bats test files so lanes does not fail in bats repos #3177's head commit 444f4e76, which is that same main plus the PR's changes.
   • The command was gstack-pregate --base main --policy-from head --allow-repo-commands --stage tests with "runner": "bats {files}".
   • The touched file was one shell script, scripts/tool, mapped with "scripts/tool": ["tests/tool.bats"]. tests/tool.bats has 40 tests.

   Case	Before (0bf9d508)	After (#3177, 444f4e76)
   script mapped to its real 40-test .bats file	fail PREGATE_NO_LANE	pass: 40 tests ran in 1 file(s), exit 0 (25.7 s)
   same, with one test broken (false)	fail PREGATE_NO_LANE	fail: local lane exited 1 (1 failed of 40 ran; 1 files; pipefail)
   script mapped to a .bats file with no @test	fail PREGATE_NO_LANE	fail: ZERO-RUN: the runner reported 0 tests for 1 selected file(s)
   no dependencies entry	fail PREGATE_NO_LANE	fail PREGATE_NO_LANE (the bats file reaches the script through $BATS_TEST_DIRNAME/../scripts/tool, which the literal scan doesn't follow, so the mapping must be declared)

   The pass, fail and zero-run paths all behave as the PR describes on a real suite. We haven't tried a lane long enough to test the stall supervisor.

   One question for the design: runner is a single command, so in a repo with both bats and node --test tests, every selected file goes to that one command.

   • One way to handle that is a wrapper runner that sends .bats files to bats and .test.mjs files to node --test. With a wrapper, though, parseSummary no longer sees bats in the runner name, so it tries the other runners' summary formats first and treats bats as a last resort.
   • Is a wrapper the intended shape for mixed repos, or would a per-extension runner (for example {".bats": "bats {files}", ".mjs": "node --test {files}"}) fit better?