Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-1524

Version handling and setting the New Code period should be more flexible

    XMLWordPrintable

    Details

    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:

      Description

      Why

      The way we deal with version strings was shaped in SonarQube's Maven-centric era, and doesn't necessarily fit with the wider array of build technologies and versioning philosophies we deal with today. For instance, within SonarSource, we now automatically append build number to the end of the version string and do some scripting to suppress that part of the string for analysis. At the same time, languages like COBOL handle versioning entirely differently - each file is an independent program and each commit is a new version in that worldview. Further, Go doesn't even have (currently) a concept of versioning.

      Additionally, we currently rely on the scanner to signal a version change, but true version change (deployment) can only be recognized in retrospect.

      These conflicts and confusions around what a "version" is muddle the concept of New Code period. If I don't have a version, or if every commit is a new version, how do we recognize when the New Code period starts?

      Brainstorming team JulienH, Fabrice, Cameron, with guest appearances by Andrea

      What

      To our current version support, we will add the ability to pinpoint a specific analysis as the baseline for the next New Code period.

      The primary expected use will be via web services from release systems (e.g. Burgr) so that will be the primary development. Exposing this in the UI as a convenience to the user will come later. We'll add a warning to the New Code Period setting description that the NCP value will be ignored in branches where a manual baseline has been chosen. We must also provide the ability to un-set a manual baseline so that a branch can revert to the project setting

      Analysis will set a 'baseline' marker on the relevant snapshot when it has not been set manually. For a manually selected baseline, the project homepage will show the analysis' timestamp, potentially linked to the Activity page with a scroll to and highlight of the relevant snapshot as a nice to have. The homepage label will also reflect that a manual baseline is in use.

      The baseline analysis will not be deletable. Currently that's only the case for the most recent analysis.

      When a manual baseline is in use, the homepage New Code Period label will say "New code: after [timestamp]" rather than "since".

      Adjust Housekeeping

      The current baseline analysis will not be subject to housekeeping. While it retains the baseline marker it will be treated as though it had an event. Once the baseline marker is removed, it will be immediately subject to normal housekeeping.

      We will not adjust housekeeping default values.

      Project page

      The New Code header value when the baseline is manually set:

      • if version event on snapshot: show version value
      • if effective version on snapshot different from projectVersion: show projectVersion value
      • else show date/timestamp of baseline analysis

      How

      Store the baseline analysis and whether it is managed manually or not per branch

      Add 2 columns to project_branch table:

      • current_baseline => analysis UUID : populated by report processing unless flag below is true
      • current_baseline_manual => boolean : can only be changed by a WS (ie. the user)

      Set current_baseline in EnableAnalysisStep, with conditions: not manual mode, and different from current value.
      The value can be obtained from periodHolder.getPeriod().getAnalysisUuid()

      New and changed web services

      Set the baseline on a long-lived branch

      Endpoint: api/project_analyses/set_baseline

      Parameters:

      • projectKey
      • branchKey – must be a long-lived branch
      • analysis_uuid

      Other notes:

      • Requires project admin permission or system admin.
      • Idempotent => no error if specified analysis is already current baseline (even if not manually set)

      Clear the baseline of a branch

      Endpoint: api/project_analyses/clear_baseline

      Parameters:

      • projectKey
      • branchKey – must be a long-lived branch

      Other notes:

      • Requires project admin permission or system admin.
      • Idempotent => no error if specified analysis is already current baseline (even if not manually set)

      Update the web service used by Activity page

      The Activity page should show the baseline marker of the current branch, and perhaps the full version strings too.

      => TODO see with UX & PM

      Housekeeping

      Exclude the analysis UUIDs used as baseline markers from purge.

      Store both the full and effective version strings

      Add a column to SNAPSHOTS table. (effective_version? ...?)

      Add a DB migration to populate the new column from version (simple copy). On SonarCloud, must be implemented as an online migration.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              ann.campbell.2 Ann Campbell
              Reporter:
              ann.campbell.2 Ann Campbell
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: