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

Lshistory polling/changelog misses certain file changes during rebase.

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • clearcase-plugin
    • None
    • Platform: All, OS: All

    Description

      Under a rebase I noticed the following behaviour.

      The files that was merged/changed as part of the rebase appeared correctly in
      the changelog, but the files which was now "just visible" because of the
      baseline change did not.

      I suspect it is because they don't appear as changed in the branch/stream.

      How can we detect such changes and is it even relevant?

      Attachments

        Issue Links

          Activity

            janwe janwe added a comment -

            I also observe this issue. I guess this happens because rebasing without merging
            something on the stream does not actually constitute a change on the stream and
            hence no change to the respective branch type.

            However, I believe it is relevant to catch such changes - if you perform builds
            off a stream which is rebased in order to bring in new files, you would want
            your build to trigger in order to include those new files in the build.

            Unfortunately I have not found a command to extract such "changes". I would
            guess that this could be accomplished by doing some monitoring on the foundation
            baseline of a stream and triggering a build if it changes. If this is
            implemented it should probably be an option the user can enable to avoid such
            monitoring if you don't have to.

            janwe janwe added a comment - I also observe this issue. I guess this happens because rebasing without merging something on the stream does not actually constitute a change on the stream and hence no change to the respective branch type. However, I believe it is relevant to catch such changes - if you perform builds off a stream which is rebased in order to bring in new files, you would want your build to trigger in order to include those new files in the build. Unfortunately I have not found a command to extract such "changes". I would guess that this could be accomplished by doing some monitoring on the foundation baseline of a stream and triggering a build if it changes. If this is implemented it should probably be an option the user can enable to avoid such monitoring if you don't have to.
            abayer Andrew Bayer added a comment -

            Assigning to me.

            abayer Andrew Bayer added a comment - Assigning to me.
            abayer Andrew Bayer added a comment -

            Not sure anything can be done about this without some really ugly hacking.
            Opting for WONTFIX.

            abayer Andrew Bayer added a comment - Not sure anything can be done about this without some really ugly hacking. Opting for WONTFIX.

            This is fixable, but you'll have to jump through a couple of hoops. The problem
            is that when you change the foundation or recommended baseline for a
            non-modifiable component, although CC will create a rebase activity for the
            change, the rebase is actually a no-op. The only thing that gets changed is one
            or another of the process variables attached to the stream object; this escapes
            the lshistory check for 2 reasons; firstly, the change isn't actually to the
            branch type; secondly, even though the change does appear in the stream history,
            the event record will not state anything other than "changed variable PVAR_FOO"
            (or whatever the variable is named), and not tell you what the actual change in
            value is.

            To resolve this, what you would need to do is, around the same time as the
            lshistory, execute a lsstream -long on the stream object (cleartool lsstream
            -long stream:WindowsForms_Int@\SHARED_PVOB, to use one example from a build
            here), and parse the output of that command to get the foundation baselines used
            for the non-modifiable components. Store that in a multidimensional array (one
            axis for the component, one axis for the build #), and the compare values
            against the last build. I have scripts that parse this output in perl; should
            probably convert to java without too much frustration.

            I would love to have this functionality within the plugin, on a personal note

            aaron_neerenberg aaron_neerenberg added a comment - This is fixable, but you'll have to jump through a couple of hoops. The problem is that when you change the foundation or recommended baseline for a non-modifiable component, although CC will create a rebase activity for the change, the rebase is actually a no-op. The only thing that gets changed is one or another of the process variables attached to the stream object; this escapes the lshistory check for 2 reasons; firstly, the change isn't actually to the branch type; secondly, even though the change does appear in the stream history, the event record will not state anything other than "changed variable PVAR_FOO" (or whatever the variable is named), and not tell you what the actual change in value is. To resolve this, what you would need to do is, around the same time as the lshistory, execute a lsstream -long on the stream object (cleartool lsstream -long stream:WindowsForms_Int@\SHARED_PVOB, to use one example from a build here), and parse the output of that command to get the foundation baselines used for the non-modifiable components. Store that in a multidimensional array (one axis for the component, one axis for the build #), and the compare values against the last build. I have scripts that parse this output in perl; should probably convert to java without too much frustration. I would love to have this functionality within the plugin, on a personal note
            abayer Andrew Bayer added a comment -

            I'm going to reopen this, recategorize it as an enhancement, and bump down the
            priority to a P4 - I'll see if I can make a run at implementing that at some
            point in the future.

            abayer Andrew Bayer added a comment - I'm going to reopen this, recategorize it as an enhancement, and bump down the priority to a P4 - I'll see if I can make a run at implementing that at some point in the future.
            davidmc24 davidmc24 added a comment -

            CC'ing

            davidmc24 davidmc24 added a comment - CC'ing

            I changed the changelog logic in order to include activities from rebase.

            The change is currently in trunk.

            vlatombe Vincent Latombe added a comment - I changed the changelog logic in order to include activities from rebase. The change is currently in trunk.

            People

              vlatombe Vincent Latombe
              lynggaard lynggaard
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: