Analysis very slow on github

  • CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI
    • GitHub

We have observed our scans taking forever. I have a GitHub build agent that has been scanning for over an hour. This is not normal but I am seeing it across multiple pull requests from other developers as well. Just this part of the log from the sonar scan has taken 1hr to produce. It normally takes a minute or less?

INFO: SCM Publisher SCM provider for this project is: git
INFO: SCM Publisher 13 source files to be analyzed
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: SCM blame is in progress..
INFO: 1/13 source file have been analyzed
// 127  more of these
INFO: 1/13 source file have been analyzed
INFO: 2/13 source files have been analyzed
// 9  more of these
INFO: 2/13 source files have been analyzed
INFO: 3/13 source files have been analyzed
// 112  more of these
INFO: 3/13 source files have been analyzed
INFO: 5/13 source files have been analyzed
// 12  more of these
INFO: 5/13 source files have been analyzed
INFO: 6/13 source files have been analyzed
INFO: 7/13 source files have been analyzed
INFO: 7/13 source files have been analyzed
INFO: 7/13 source files have been analyzed
INFO: 7/13 source files have been analyzed
INFO: 8/13 source files have been analyzed
INFO: 8/13 source files have been analyzed
INFO: 9/13 source files have been analyzed
INFO: 11/13 source files have been analyzed
INFO: 11/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed
INFO: 12/13 source files have been analyzed

and it is still going. Just this snippet of my build log took around 1hr to produce.

Looking at our history this potentially started 3 days ago when this filter: tree:0 was added to the checkout.

      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          filter: tree:0

I removed the filter: tree:0 and it did in fact fix the issue of scans taking 1 hours instead of 1-2 minutes.

But I do not why.

1 Like

It would be nice to have some insight on how this option affects things and why it makes something that should take seconds, take an hour.

Hi,

I couldn’t find a lot on filter: tree:0, but what I did find indicates that means things are fetched lazily instead of as part of the initial clone. So I suspect there’s time spent waiting for this lazy fetch that isn’t actually invoked…? What was your understanding of the option when you added it to your pipeline?

 
Ann

It was added because we use a too MinVer to automatically generate versions in the pipeline. GitHub - adamralph/minver: 🏷 Minimalistic versioning using Git tags.

Since it uses tags to generate the build number it doesn’t really need the actual full history just enough to know the tags. This was their recommendation

For GitHub Actions, set the fetch-depth of the checkout action to an appropriate number, or to zero for all commits (you can also set filter to tree:0 to create a treeless clone, for better performance). For example:

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
    filter: tree:0

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.