You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the current behavior?
detect-secrets-hook gets a list of files as command line arguments.
What is the desired behavior?
detect-secrets-hook optionally reads a list of files from a file.
What is the motivation / use case for changing the behavior?
The documentation suggest using xargs to construct and run the detect-secrets-hook command line. A problem with this approach is that the caller of xargs, such as a git pre-commit hook or build pipeline, gets the exit code from xargs, not detect-secrets-hook.
I want to distinguish between detect-secrets-hook's exit code 1 (found a secret) and exit code 3 (no new secrets, but updated the baseline, e.g. from 1.4.0 to 1.5.0). In the latter case I don't want to block the commit or build pipeline. But xargs returns the same exit code, 123, in both cases.
If detect-secrets-hook could read a list of files from a file, we could call detect-secrets-hook directly, without xargs, and receive the detect-secrets-hook exit code. This would also help when there are many files to scan: If the command line constructed by xargs is long, it may call detect-secrets-hook multiple times. Using a file as input, detect-secrets-hook could run just once.
Using xargs can also cause problems when many files are being scanned: If the detect-secrets-hook command line would be longer than xargs' limit (128 Kb characters), xargs will run detect-secrets-hook multiple times with a shorter command line. If the first run of detect-secrets-hook modifies the baseline, any additional runs will fail with "Your baseline file (.secrets.baseline) is unstaged."
Because filenames may contain newlines, there should also be an option like xarg's --null (-0) for reading null-terminated strings from the file.
Please tell us about your environment:
detect-secrets Version: 1.5.0
Python Version: 3.11.2
The text was updated successfully, but these errors were encountered:
Upgrading from detect-secrets 1.4 to 1.5 is causing problems for us because detect-secrets-hook 1.5 updates the baseline file even if no new secrets are found. It returns exit code 3 in this case, causing failures in our build pipelines. I'd like to ignore that case, but it's difficult to get the exit code when using xargs.
I'm submitting a ...
What is the current behavior?
detect-secrets-hook gets a list of files as command line arguments.
What is the desired behavior?
detect-secrets-hook optionally reads a list of files from a file.
What is the motivation / use case for changing the behavior?
The documentation suggest using xargs to construct and run the detect-secrets-hook command line. A problem with this approach is that the caller of xargs, such as a git pre-commit hook or build pipeline, gets the exit code from xargs, not detect-secrets-hook.
I want to distinguish between detect-secrets-hook's exit code 1 (found a secret) and exit code 3 (no new secrets, but updated the baseline, e.g. from 1.4.0 to 1.5.0). In the latter case I don't want to block the commit or build pipeline. But xargs returns the same exit code, 123, in both cases.
If detect-secrets-hook could read a list of files from a file, we could call detect-secrets-hook directly, without xargs, and receive the detect-secrets-hook exit code. This would also help when there are many files to scan: If the command line constructed by xargs is long, it may call detect-secrets-hook multiple times. Using a file as input, detect-secrets-hook could run just once.
Using xargs can also cause problems when many files are being scanned: If the detect-secrets-hook command line would be longer than xargs' limit (128 Kb characters), xargs will run detect-secrets-hook multiple times with a shorter command line. If the first run of detect-secrets-hook modifies the baseline, any additional runs will fail with "Your baseline file (.secrets.baseline) is unstaged."
Because filenames may contain newlines, there should also be an option like xarg's
--null (-0)
for reading null-terminated strings from the file.Please tell us about your environment:
The text was updated successfully, but these errors were encountered: