v1.3.0+ scans entire history on push

[stone-z]

Following this PR, the behavior on push is to scan the entire history, which I think is not actually intended.

In this PR, for example, two gitleaks jobs run - one for pull_request and one for push. The PR job is both much faster (14s vs 1m) and also passes, while the push job fails due to a very old match.

I'm not sure what the perfect way forward is. I can understand the use case of wanting to scan multiple pushed commits, but for performance and to limit the effort for users I think it should still be bounded to only those commits. On a PR branch it is clear how far back to scan, but it's harder when committing directly to a branch. Maybe a better git wizard than I has an idea?

cc @niall-byrne @zricethezav

[niall-byrne]

This is totally possible, I believe you can control the number of commits you check out with actions/checkout@v2.

[stone-z]

This is totally possible, I believe you can control the number of commits you check out with actions/checkout@v2.

For sure, I think the question still remains how to determine how many commits to check out. If the commits are known, we could also use the same approach as is used for PRs (with the commit list). But a user could push arbitrarily many commits in a single push, and I haven't yet managed to find a git- or GitHub-native way to see what they are.

[niall-byrne]

https://github.community/t/how-to-get-all-pushed-commit-information/116861/3

[stone-z]

😮 yeah that looks like it should work. I'll cook up a PR. Thanks!

[crazy-matt]

I believe the scan is performed on all branches as the gitleaks action does not allow to pass the --branch parameter to narrow down the scan. Which leads to some issues on the push event when working as a team with multiple feature branches.

[crazy-matt]

☝🏼 potential fix: #38

[zricethezav]

Hi @stone-z as you already know, we released version 2.0 which fixes this problem. Only relevant commits will be scanned.