SonarQube
  1. SonarQube
  2. SONAR-2119

Separate Sonar Analysis from Database Update

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Database
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In a large organization, there's a strong benefit to having a central Sonar server for reporting and management but multiple build environments managed by different teams. These could well be geographically dispersed. In the current Sonar architecture, database updates occur as part of the Sonar Analysis. If the location database server is on another network from where the analysis is run, the length of time for the analysis can be considerable due to network latency.

      The feature requested is to create an offline/batch mode for processing where the analysis could be run and a SQL or XML file generated instead of writing directly to the database. The file could then be processed later. Separating the Sonar analysis from the database update would free up the CI server on the build machine to perform builds. The database update could then be run separately, the cost being the delay in seeing the results.

      Another benefit would be for really large analysis that run multiple hours. If the database connection fails, the analysis needs to be re-run. In batch mode, the analysis data could be generated and moved to the database server (via scp, etc). The data could then be incorporated into the database using a local SQL connection removing the network issue.

        Issue Links

          Activity

          Hide
          Fabrice Bellingard added a comment -

          FYI guys, our goal is to reach this target by the end of 2014.

          Show
          Fabrice Bellingard added a comment - FYI guys, our goal is to reach this target by the end of 2014.
          Hide
          David M. Karr added a comment -

          Freddy, just to be clear, I assume you mistyped when you said "we're currently hardly working on this ticket"?

          Show
          David M. Karr added a comment - Freddy, just to be clear, I assume you mistyped when you said "we're currently hardly working on this ticket"?
          Hide
          Julien HENRY added a comment -

          French typical mistake. Should be => we are working very hard on this ticket

          Show
          Julien HENRY added a comment - French typical mistake. Should be => we are working very hard on this ticket
          Hide
          Mehul Dixit added a comment -

          Any further update on this ticket.

          Show
          Mehul Dixit added a comment - Any further update on this ticket.
          Hide
          Fabrice Bellingard added a comment - - edited

          We've started removing access to DB since a couple of versions. This is a long task that spans over multiple versions and that requires a lot of technical refactoring under the hood, as well as the implementation of a new "compute engine" stack on server side (that is also under development).
          We target SQ 5.2 (Q2 2015) for the full removal of DB access.

          Show
          Fabrice Bellingard added a comment - - edited We've started removing access to DB since a couple of versions. This is a long task that spans over multiple versions and that requires a lot of technical refactoring under the hood, as well as the implementation of a new "compute engine" stack on server side (that is also under development). We target SQ 5.2 (Q2 2015) for the full removal of DB access.

            People

            • Assignee:
              Unassigned
              Reporter:
              John M. Vogtle
            • Votes:
              55 Vote for this issue
              Watchers:
              39 Start watching this issue

              Dates

              • Created:
                Updated: