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

Missing defect/activity summarization level in clearcase change history

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • clearcase-plugin
    • None

      The clearcase change history is summarized by delivery, with all file changes enumerated. For our users, the CQ defect number or activity number and headline is very important to knowing whether a particular build should be deployed in a given test environment.

      For example, say that defect 1234 is blocking some tests and they don't want to take another build until 1234 is fixed. There's no way to tell from the current change history whether a fix for that defect was delivered in a build except perhaps either polling CQ or digging into changesets.

      Something like this would be desired:

      1. deliver some_stream on sometimestamp by someuser
      a) DEF00012345 - The Defect's headline
      Files:
      23/02/2010 15:42: path\to\file.extension version \main\intg_stream\12
      b) DEF00012346 - Other Defect's headline
      Files:
      23/02/2010 15:42: path\to\otherfile.extension version \main\intg_stream\11

      2. deliver someother_stream on someothertimestamp by someotheruser
      ...

          [JENKINS-5743] Missing defect/activity summarization level in clearcase change history

          grimmrimmer added a comment -

          This would be extremely useful as most people have a CC/CQ setup with assigned defect number attributes given to each versioned object. I'm not sure if this should cover customizing what's displayed on the "changes" tag by allowing users to add version attributes to the "changes" string.

          Also, does anyone know if a workaround for this is possible (besides modifying the source)?

          grimmrimmer added a comment - This would be extremely useful as most people have a CC/CQ setup with assigned defect number attributes given to each versioned object. I'm not sure if this should cover customizing what's displayed on the "changes" tag by allowing users to add version attributes to the "changes" string. Also, does anyone know if a workaround for this is possible (besides modifying the source)?

          I do not have access to CQ, but I guess this attribute can be retrieved by adding %a to the -fmt used by lshistory command. In which case, change log could be decorated with these extra attributes. In any case, I don't think this can be done without changing the code. If you want to make a patch on this, feel free to do so.

          Vincent Latombe added a comment - I do not have access to CQ, but I guess this attribute can be retrieved by adding %a to the -fmt used by lshistory command. In which case, change log could be decorated with these extra attributes. In any case, I don't think this can be done without changing the code. If you want to make a patch on this, feel free to do so.

          dhauslad added a comment -

          I'm buried at work but in a few weeks I may have time to put a patch together.

          dhauslad added a comment - I'm buried at work but in a few weeks I may have time to put a patch together.

            Unassigned Unassigned
            dhauslad dhauslad
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: