fix(logs): bypass pager when --tail is active#253
Conversation
Summary of ChangesHello @jdx, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request correctly fixes an issue where the pager would block when using pitchfork logs --tail. The change to bypass the pager is simple and effective. The addition of a bats testing framework with integration tests for the logs command is a great improvement for the project's stability. The new tests cover the fix and related functionality well. I've pointed out a minor potential issue in one of the new test scripts to make it more robust. Overall, this is a solid contribution.
| assert_output --partial "tick" | ||
| # Should have at most 3 lines | ||
| local line_count | ||
| line_count="$(echo "$output" | wc -l | tr -d ' ')" |
There was a problem hiding this comment.
Using echo "$output" can be problematic for counting lines, as echo may add an extra newline character depending on its implementation and the content of $output. This can cause wc -l to report an incorrect line count. Using printf '%s' is a more reliable way to print the exact content of the variable without modifications, ensuring the line count is accurate.
line_count="$(printf '%s' "$output" | wc -l | tr -d ' ')"
There was a problem hiding this comment.
Pull request overview
This PR fixes pitchfork logs --tail by bypassing the pager so streaming starts immediately, and adds Bats-based integration tests to validate --tail, -n, and --follow.
Changes:
- Skip pager when
--tailis active by streaming logs directly to stdout. - Add Bats submodules and shared test setup helpers.
- Add integration tests covering
--tail,-n, and--followbehavior.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| src/cli/logs.rs | Ensures --tail bypasses the pager by streaming directly. |
| test/logs.bats | Adds Bats tests validating tail/follow behavior and -n output. |
| test/test_helper/common_setup.bash | Introduces shared Bats setup/teardown and helper wait functions. |
| .gitmodules | Adds Bats + helper libraries as git submodules. |
| test/bats | Pins bats-core submodule revision. |
| test/test_helper/bats-support | Pins bats-support submodule revision. |
| test/test_helper/bats-assert | Pins bats-assert submodule revision. |
| test/test_helper/bats-file | Pins bats-file submodule revision. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
test/logs.bats
Outdated
| run timeout 3 pitchfork logs ticker --tail --raw | ||
| # timeout exits 124 when it kills the child — that's expected | ||
| assert_output --partial "tick" | ||
| refute_output --partial "(END)" |
There was a problem hiding this comment.
These timeout-based tests can produce false positives because they never assert the expected timeout exit status (typically 124). If pitchfork logs ... --tail unexpectedly exits early after printing a line, the test would still pass. Consider asserting the exit status explicitly (and/or assert_failure) so the test guarantees the command was still running when killed by timeout.
test/logs.bats
Outdated
| # --tail should stream directly to stdout without spawning a pager. | ||
| # If it opens a pager (less), the process will block waiting for input and | ||
| # timeout will kill it, producing no output (or "(END)" from less). | ||
| run timeout 3 pitchfork logs ticker --tail --raw |
There was a problem hiding this comment.
Relying on the external timeout command can make the test suite less portable (e.g., environments where GNU timeout isn’t available, or it’s named differently). Consider adding a small helper in common_setup.bash that provides a consistent cross-platform timeout wrapper (e.g., detect timeout vs gtimeout, or implement a simple alarm-based wrapper) and use that helper in these tests.
test/logs.bats
Outdated
| pitchfork start ticker | ||
| wait_for_log_lines ticker 3 | ||
|
|
||
| run timeout 3 pitchfork logs ticker --follow --raw |
There was a problem hiding this comment.
Relying on the external timeout command can make the test suite less portable (e.g., environments where GNU timeout isn’t available, or it’s named differently). Consider adding a small helper in common_setup.bash that provides a consistent cross-platform timeout wrapper (e.g., detect timeout vs gtimeout, or implement a simple alarm-based wrapper) and use that helper in these tests.
| local daemon="$1" | ||
| local expected="$2" | ||
| for _ in $(seq 1 50); do | ||
| if pitchfork status "$daemon" 2>/dev/null | grep -q "$expected"; then |
There was a problem hiding this comment.
Using grep -q \"$expected\" treats expected as a regular expression, which can lead to unintended matches if the expected status contains regex metacharacters. Using fixed-string matching (e.g., grep -Fq -- \"$expected\") makes the helper more robust and avoids regex-related surprises.
| if pitchfork status "$daemon" 2>/dev/null | grep -q "$expected"; then | |
| if pitchfork status "$daemon" 2>/dev/null | grep -Fq -- "$expected"; then |
When using `pitchfork logs <daemon> --tail`, the pager (less) would open and block with "(END)", requiring the user to press q before tailing actually started. Now --tail skips the pager and streams directly to stdout so tail_logs() runs immediately. Also adds bats test infrastructure (mirroring garni's pattern) with PTY-based tests that verify the pager is actually bypassed. Tests use `script` to allocate a PTY so is_terminal() returns true, ensuring the pager code path is exercised. Bats tests run in CI via mise. Closes #252 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
8dfd1d9 to
c109cc7
Compare
|
bugbot run |
Summary
pitchfork logs <daemon> --tail, the pager (less) would open and block with(END), requiring the user to pressqbefore tailing actually started. Now--tailskips the pager and streams directly to stdout sotail_logs()runs immediately.--tail,-n, and--followCloses #252
Test plan
cargo nextest run— all 164 tests passtest/bats/bin/bats test/logs.bats— all 3 new bats tests passpitchfork logs <daemon> --tailstreams without opening pager🤖 Generated with Claude Code
Note
Low Risk
Small, isolated CLI behavior change plus test/CI plumbing; main risk is altered pager behavior for interactive users when tailing.
Overview
Fixes
pitchfork logs --tail/--followto skip the pager even in an interactive terminal, streaming logs directly to stdout so tailing starts immediately.Adds bats integration test infrastructure via git submodules and a shared
common_setup, introduces newtest/logs.batscoverage for--tail,--follow, and-n/--raw, and updatesmise/GitHub Actions CI to fetch submodules and run the bats test suite.Written by Cursor Bugbot for commit 3b14a2e. This will update automatically on new commits. Configure here.