Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-3862

Allow configuration of base directory for Cobertura report XML files

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • cobertura-plugin
    • None
    • Platform: All, OS: All

      Currently, the Cobertura plugin configuration has a "Cobertura xml report pattern". In this box,
      you enter an expression that identifies which files you wish to be considered for Cobertura
      reporting. However, there is currently no way to configure which directory this pattern is relative
      to. It does not allow you to enter system-wide absolute paths, nor does it allow relative paths
      that go outside of the base directory using "..". This can be problematic for users whose build
      scripts (Ant build.xml, etc.) generate the Cobertura XML files within the workspace, but not
      within the module root, or in a location outside the workspace entirely. In many cases, the plugin not
      recognizing these files was misreported as a bug (see Issue 1423).

      To support these use cases, I suggest the following:
      -Add a new "advanced" configuration text field, "Cobertura xml report base directory"
      -If the value is not specified/blank, treat it as if it contains ${DEFAULT} (see below)
      -If the value contains the expression ${DEFAULT}, replace that with the absolute
      path of the same directory as is currently used by default (module root unless
      multi-module Subversion, in which case workspace root)
      -If the value contains the expression ${MODULE_ROOT}, replace that with the absolute
      path of the module root
      -If the value contains the expression ${WORKSPACE}, replace that with the absolute
      path of the workspace root
      -When publishing cobertura results, evaluate the "Cobertura xml report pattern" relative to the
      "Cobertura xml report base directory".

      By putting the field in the Advanced section, this should prevent the new option from overly
      inconveniencing users who don't need it. By keeping the behavior the same when the new field is
      blank, we should preserve backwards-compatibility with existing configurations. By allowing arbitrary
      absolute paths, or paths relative to either the module root or workspace, we should hopefully meet the
      needs of all users.

            Unassigned Unassigned
            davidmc24 davidmc24
            Votes:
            10 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: