Ensure enough commits for a commit-range scan
What does this MR do?
A scan performed on a branch with zero new commits is modelled as a commit-range scan. The range begins at the parent of the HEAD commit on the new branch and ends at the HEAD commit. If we have a situation where the repository only has a single commit, this operation fails because it won't be able to get the parent of the only commit in the repo. This change adds a check to ensure enough commits exist for a commit-range scan. If the repo only contains a single commit, no options are supplied to gitleaks and a --no-git scan is performed instead.
You can see evidence of the old behaviour in this test repo.
There are three branches:
- main -- contains two commits
- new-branch -- branched off main when it had only a single commit
- new-new-branch -- branched off main when it had two commits
The pipeline in new-branch is failing because the repository only contained a single commit at that time, but it was still trying to perform a commit-range scan starting at the parent of the only commit. The pipeline in new-new-branch succeeds because two commits are present in the repo now.
What are the relevant issue numbers?
- gitlab-org/gitlab#331796 (closed) (not specifically related to this change, but I did discover this problem while investigating this issue).
Does this MR meet the acceptance criteria?
-
Changelog entry added -
If you are adding a new rule, a link to a regex101 example is included in the description -
Documentation created/updated for GitLab EE, if necessary -
Documentation created/updated for this project, if necessary -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Job definition updated, if necessary -
Conforms to the code review guidelines -
Conforms to the Go guidelines -
Security reports checked/validated by reviewer