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

testscript: stable error output [feature request] #286

Open
jpluscplusm opened this issue Jan 26, 2025 · 0 comments
Open

testscript: stable error output [feature request] #286

jpluscplusm opened this issue Jan 26, 2025 · 0 comments

Comments

@jpluscplusm
Copy link

This is a feature request either:

  • for a CLI flag to enable the behaviour described below, or
  • for the default behaviour of the testscript command to be updated to match this behaviour
    • with an optional CLI flag to opt back into the current behaviour.

Feature Request

Please consider adding a flag which causes the output from testscript in a failing context to be stable.

Rationale

Currently, both the stderr and stdout of a failing invocation include an unstable testscript[0-9]{10} path component tracking where the txtar archive was unpacked on the filesystem:

$ testscript test.txtar 
> ! exec true
FAIL: /tmp/testscript3999957216/test.txtar/script.txtar:1: unexpected command success
error running test.txtar in /tmp/testscript3999957216/test.txtar
$ testscript test.txtar 
> ! exec true
FAIL: /tmp/testscript1000854673/test.txtar/script.txtar:1: unexpected command success
error running test.txtar in /tmp/testscript1000854673/test.txtar

Its inclusion means that any automation that tracks/matches/enforces the output from such a failing test needs to special case recognising that path component, just in order to ignore it.

I don't believe that the significant majority of users running testscript will need to know this temporary prefix / path; and in the small minority of cases where it's important, then those situations have the -work flag available ("... prints the temporary work directory path before running each script"). I believe it would be harmless to drop the prefix when reporting an error, with an optional flag causing the command to revert to the current, unstable, output.

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

No branches or pull requests

1 participant