Invalid range error when Secret Detection runs against rewritten history
Summary
In certain cases we may throw an error and fail the Category:Secret Detection job run through a Scan Execution Policy when a repository's history is rewritten. The error looks as follows:
[WARN] [secrets] [2023-03-30T18:24:32Z] [/go/src/app/analyze.go:262] ▶ Error encountered when running git command: /usr/bin/git log --pretty=format:"%H" 34b751fd2b8036e191b5208b2acd3f4bd55d7a6f..b6fcacf29ef79dcf0b680662747cb18a18f54453
output: fatal: Invalid revision range 34b751fd2b8036e191b5208b2acd3f4bd55d7a6f..b6fcacf29ef79dcf0b680662747cb18a18f54453
error:exit status 128
This is a result of the SECRET_DETECTION_LOG_OPTIONS
range being injected no longer matching the contents of the history. We should handle these scenarios gracefully.
Steps to reproduce
- Create a project with secret detection enabled via a Scan Execution Policy
- Push some code changes
- Rewrite the history locally (i.e. squash some commmits)
- Force push to branch
- Note failing CI job
Example Project
What is the current bug behavior?
Secret Detection job fails with fatal: Invalid revision range
error
What is the expected correct behavior?
Secret Detection job should not fail when injected SECRET_DETECTION_LOG_OPTIONS
do not match cloned repository.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Possible fixes
Edited by Lucas Charles