SonarCFamily cache path configuration

SonarQube Server / Community Build
1

For the incremental feature, I have enabled it and set:

sonar.cfamily.cache.enabled=true
sonar.cfamily.cache.path=C:\sonar-cache\my-driver\

“my-driver” being the project key. Do I need to append the branch to the path also? What path format does the PR build look for when running?

3

Hi @jlawless,

I moved your post to a new topic.

4

Hi @jlawless,

it depends from your CI setup.

Many CI systems keep a main cache for the master branch and make a copy of it when a branch/PR is created. In such common case the path should not be customised with the branch name and it can be as you wrote (C:\sonar-cache\my-driver\) because branches cache will be forked from the master branch.

5

Ah ok, it kind of sounds like I should do the following, can you confirm:

when master builds

  • cache to C:\sonar-cache\my-driver\

when other branches build

  • Take a copy of C:\sonar-cache\my-driver\ (say, copy to C:\vsts-agent_work\1\s\sonar-cache\my-driver)
  • modify the sonar.cfamily.cache.path to C:\vsts-agent_work\1\s\sonar-cache\my-driver\
  • run analysis.

Is this correct? That way, the copy is a throwaway, and only used during that analysis.

How about when feature branches get involved? e.g.
master - cached to C:\sonar-cache\my-driver
features/my-feature - analysis ran - output not cached?
jl/my-addition-to-a-feature - Doing a PR from this branch to features/my-feature.

When running my CI analysis build on my PR (from jl/… to features/…), what should sonar.cfamily.cache.path be set to? Because C:\sonar-cache\my-driver\ would point to the last master run.

6

Hi @jlawless,

aren’t you using ephemeral machines? Do you share workspaces between builds?

This approach should work yes.

One note, the cache is not meant for parallel analysis accessing the same cache instance.

7

Yeah, we do. Well, ephemeral workspaces at least (but builds should not be dependant on data on the machine).

So I think I understand now, going to try and phase it out below:

CI build:

---
steps:
- checkout: self
- powershell: |
    # Copy cached analysis from \\remotestorage\sonar-cache\my-driver\
    # to $(Build.SourcesDirectory)\sonar-cache\my-driver\
- task: SonarQubePrepare@4
  inputs:
    SonarQube: '[PRODUCTION] SonarQube'
    projectKey: 'my-driver'
    projectName: 'My Driver'
    projectVersion: '$(newCodePeriod)'
    extraProperties: |
      sonar.cfamily.build-wrapper-output=$(Build.StagingDirectory)
      sonar.cfamily.cache.enabled=true
      sonar.cfamily.cache.path=**$(Build.SourcesDirectory)\my-driver\**
- powershell: |
    # Build software
- task: SonarQubeAnalyze@4
  displayName: 'Run SonarQube analysis'

- task: SonarQubePublish@4
  displayName: 'Publish Quality Gate Result'

- powershell: |
    # Upload $(Build.SourcesDirectory)\my-driver\ 
    # to \\remotestorage\sonar-cache\my-driver\ ONLY ON MASTER
  condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
  1. Run CI build on master
  2. branch master (jl/my-feature)
  3. Open PR
  4. CI build runs, copies master build analysis, then runs incrementally, due to the files being on disk.

Is this (at least somewhat) correct?

Assumably this means I can get it working for PRs into feature branches, by caching them also and using the TargetBranch to copy the correct cache when doing the PR?

Thanks

8

Hi @jlawless,

yes, it looks good. In that way you have only master branch updating the cache and PRs working over master cache, this pattern looks good.

If you have long living branches or feature branches you can consider storing caches for branches too. It really depends from your workflow.

1 Like
9

A post was merged into an existing topic: SonarCFamily Cache Question