Invalid range error when Secret Detection runs against rewritten history

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

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

1. Create a project with secret detection enabled via a Scan Execution Policy
2. Push some code changes
3. Rewrite the history locally (i.e. squash some commmits)
4. Force push to branch
5. 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