fix not being able to scan from subdirectories #774
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.
bug fix
When running
detect-secrets scan
from a subdirectory of the git root, no results will be returned (unless--all-files
was specified). This doesn't seem to be intentional, as the path handling implies that the current directory may well be in some other place.Compare
detect-secrets scan docs
in this repository with(cd docs && detect-secrets scan)
, the former returns hits fordocs/design.md
anddocs/filters.md
, the latter doesn't.Why is it desirable to have these behave the same? Apart from it being weird if the program silently returns nothing with unexpected arguments, well, for example you might have a monorepo and just want to scan a subdirectory of it. When
detect-secrets
is being called from another tool, you might not necessarily be aware where the git root is and would have to first navigate there, then pass the path to the subdirectory explicitly, instead of just runningdetect-secrets scan
from where you currently are.Not a new feature, you'll just be able to run
detect-secrets scan
from a subdirectory and things will still work.Unless someone accidentally relied on no results being returned (I'd bet that'd always be a mistake), this is not a breaking change and might surface some secrets which were previously ignored if the program was called like described above.