Conversation
Every notification since the action landed has failed with exit 127 in about 16ms, so the alert never reached Discord — including the smoke-test failures the schedule fires on main. The action executed the script directly and relied on `#!/usr/bin/env bash`. The self-hosted runners are NixOS: the step's own shell is an absolute /nix/store path and bash is not on PATH, so env cannot resolve an interpreter and exec fails 127. gaia had this right before the move. It called `bash .github/scripts/discord-notify.sh`, which never consulted the shebang; turning that into a direct execution is what introduced this. The callers set fail-on-undeliverable: false, so the lost alert did not fail their jobs — a notification that silently does not arrive, which is the failure this action exists to prevent, in a new place.
bjornars
marked this pull request as draft
August 28, 2026 12:40
bjornars
changed the title
Contributor
Author
|
Closing as invalid — the diagnosis was wrong. The step's stderr says The action is fine. The fix belongs in the runner config, alongside the gnumake and python3 entries that exist for the same reason — a hosted ubuntu image ships jq and these VMs do not. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This PR is based on a wrong diagnosis. Do not merge it. The comment it adds to
action.ymlasserts something false —bashIS on these runners' PATH, viapkgs.bashinextraPackages.The real cause, from the step's actual stderr rather than my theorising:
The interpreter resolved and the script ran. It died calling
jq, which is not installed on the self-hosted runners —sisyphus/guest.nixlists bash, coreutils, gnumake, glibc.bin, python3, gnupg, docker, git, nix and openssh, and no jq.That puts jq squarely in the category
guest.nixalready documents for gnumake and python3: something a hosted ubuntu image ships and this VM does not. So the fix is one line there, not here.The alternative — dropping the jq dependency and encoding JSON in bash — is worse.
contentexists precisely so the action does the encoding centrally and a PR title containing a quote cannot produce invalid JSON. Hand-rolling that escaping reintroduces the class of bug the input was added to remove.Left open only so the wrong reasoning is visible next to the right one. Close it once the runner change lands.