fix(ci): actually add grep -e (a3d3a45 claimed it and did not)

The previous commit message listed this fix; the edit never made it into the tree. Checked because I have done exactly that before, and the message is not the change. Verified rather than assumed, and the behaviour is worth recording: with a password beginning with "-", `grep -rqF "$PW"` returns 0 against a directory containing no such string, so the scrub check would have reported a leak that did not exist and failed the step with a misleading message. With -e it correctly returns 1 when clean and 0 when the credential really is present. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-12 17:52:57 -04:00
parent a3d3a45e7e
commit 274451e89c
1 changed files with 4 additions and 1 deletions
@@ -108,7 +108,10 @@ jobs:
          # write ~/.netrc or ~/.config/go/env. Guarded on a non-empty secret:
          # `grep -F ""` matches every file, so a secretless run (fork PR) would
          # fail here with a message accusing it of leaking nothing.
-          if [ -n "${REGISTRY_PASSWORD:-}" ] && grep -rqF "$REGISTRY_PASSWORD" "$HOME" 2>/dev/null; then
+          # -e, so a password beginning with "-" is a pattern and not options:
+          # without it the check errors out and, under `set -e`, fails the step
+          # with a message about grep usage rather than about credentials.
+          if [ -n "${REGISTRY_PASSWORD:-}" ] && grep -rqF -e "$REGISTRY_PASSWORD" "$HOME" 2>/dev/null; then
            echo "::error::registry credential still present under \$HOME after scrub"
            exit 1
          fi