Redo: Handle execveZ failures in Command.zig
tests
#3176
Merged
+58
−14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#3130 do over. Github seems to have lost track of the fork status for the previous work. (perhaps permissions?). Rebased the PR to main as I can't see why it could possibly fail.
Previous description
Bit of a rabbit hole came up while trying to package ghostty for nixos. zig build test would just hang when run as part of checkPhase in a nix build. (rather than the nix develop ... command run in CI).Here's what I understand so far:
/usr/bin/env does not exist in a nix build sandbox. This only works as a test binary when running in nix develop as it shares its environment with the user where this compatibility crutch exists.
When executing Command.zig tests that reference /usr/bin/env the eventual call to fork+execevZ will duplicate the running test process as execevZ returns rather than dissapearing into the new exec'd process. Duplicating a test process via fork does unexepected things. zig build test will hang for <reasons?>. A test binary created via -Demit-test-exe will run two copies of the test suite producing two different failure outputs for the same test. (or ~4 copies of the test framework, one extra for each test that fails this way)
/bin/sh can be used and an alternative test target. It isn't amazing as it's relying on stdenv creating /bin/sh and it just existing on user systems. Other alternatives I can think of would require build flags or some sort of contract with packaging around what binary will exist for the Command.zig tests.