Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buttercup --no-skip causes spec text to be printed twice #251

Open
snogge opened this issue Aug 24, 2024 · 3 comments
Open

buttercup --no-skip causes spec text to be printed twice #251

snogge opened this issue Aug 24, 2024 · 3 comments
Labels

Comments

@snogge
Copy link
Collaborator

snogge commented Aug 24, 2024

buttercup --pattern x --no-skip with color causes the spec text to be printed twice, like

Suite text
  spec text   spec text   (2ms)

instead of

Suite text
  spec text   (2ms)

This happens both for passing and failed specs.

@snogge snogge added the bug label Aug 24, 2024
@sellout
Copy link

sellout commented Oct 17, 2024

I have a similar issue. I’m running buttercup via Eldev, so I’m not exactly sure of the invocation.

The context I’m running in is nix build, color works, but apparently \r doesn’t. I saw #181, and so I’ve also set GITHUB_ACTION=1.

I printed these from my suite to ensure the definitions are as expected, and Eldev or something isn’t modifying the environment.

GITHUB_ACTION: 1
NO_COLOR: nil
buttercup-color: t

It seems like the line below should match and disable batch preprint.

(and (getenv "GITHUB_ACTION") buttercup-color)

If that were working, I would suggest maybe replacing the getenv there with a reference to something like (defcustom buttercup-preprint (not (getenv "GITHUB_ACTION"))) … or, even better, if there’s some way to figure this out from the terminfo db (I have no idea). But as it is, it seems like what I have should prevent the double printing, but it’s not.

@snogge
Copy link
Collaborator Author

snogge commented Oct 18, 2024

Can you share the project you are working on and how to trigger the problem?
It would really help me if I can have a step by step instruction starting with cloning the repo.

sellout added a commit to sellout/auto-dark-emacs that referenced this issue Oct 18, 2024
Sets `GITHUB_ACTION` and adds some debugging output to the test suite.
sellout added a commit to sellout/auto-dark-emacs that referenced this issue Oct 18, 2024
Sets `GITHUB_ACTION` and adds some debugging output to the test suite.
@sellout
Copy link

sellout commented Oct 18, 2024

Sure! The most recent case (and least convoluted instance, probably) is LionyxML/auto-dark-emacs#74.

You can see it happening in CI at https://garnix.io/build/n0l2kX39 (expand the section labeled “checkPhase” just past halfway down).

That PR doesn‘t have GITHUB_ACTION=1 since it wasn’t working, but I put up a branch specifically for replication: https://github.com/sellout/auto-dark-emacs/tree/buttercup-replication

nix build github:sellout/auto-dark-emacs/buttercup-replication -L should replicate it without even needing to clone.

Also, in putting together this branch, I realized that it doesn’t need to be run in a Nix build to see this behavior.

Running it at the command line, I get doubled output (colored, which doesn’t translate to GFM)

$ GITHUB_ACTION=1 eldev test --test-type=main
Buttercup version: buttercup-1.36
GITHUB_ACTION: 1
NO_COLOR: nil
TERM: xterm-16color
buttercup-color: t
Running 6 specs.

when disabled
  shouldn’t affect enabled themes  shouldn’t affect enabled themes (2.16ms)
…

And in a Nix build (also colored)

$ nix build -L
…
emacs-auto-dark> Buttercup version: buttercup-20240328.2016
emacs-auto-dark> GITHUB_ACTION: 1
emacs-auto-dark> NO_COLOR: nil
emacs-auto-dark> TERM: xterm-256color
emacs-auto-dark> buttercup-color: t
emacs-auto-dark> Running 6 specs.
emacs-auto-dark> when disabled
emacs-auto-dark>   shouldn’t affect enabled themes  shouldn’t affect enabled themes (2.22ms)
…

I get different Buttercup versions (newer outside of Nix), but both have the GITHUB_ACTION line in them. Also I do run other software in the same terminal/shell that uses \r to clear lines and succeeds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants