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

When load rules or config spec changes, view is recreated

    XMLWordPrintable

Details

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

    Description

      For a clearcase configuration that has the "Use update" feature, the view gets
      removed and recreated when the load rules or config spec changes (e.g. from a
      rebase). Instead of doing the view recreation, we should just use setcs/update.

      Here is the related email thread:

      From: Andrew Bayer andrew.bayer@gmail.com
      Sent: Tuesday, May 12, 2009 9:57 AM
      To: Weden Jason-RWC467
      Subject: Re: ETA on 0.8.5 or 0.9?

      Yeah, there isn't a bug number, 'cos weirdly enough, this doesn't actually seem
      to be a bug. It seems to have been a really, really strange design decision at
      some point along the way. In any case, if you'd like to open one at
      http://hudson.dev.java.net, I can use that for tracking purposes, if you'd like.

      A.

      On Tue, May 12, 2009 at 6:50 AM, Weden Jason-RWC467 <jweden@motorola.com> wrote:

      Thanks for your prompt reply. If there is a bug number I can track now and a
      dev build I can grab at that time, just let know.

      Regards,

      Jason Weden
      FTTP AXSVision Software Development
      Access Networks, Home and Networks Mobility
      Motorola, Inc.
      978-614-3182

      --------------------------------------------------------------------------------
      From: Andrew Bayer andrew.bayer@gmail.com
      Sent: Tuesday, May 12, 2009 9:48 AM
      To: Weden Jason-RWC467
      Subject: Re: ETA on 0.8.5 or 0.9?

      Not quite yet - I'm fairly sure I've got the functionality change nailed down,
      but it'll probably be another week or two - I've got to set up a test
      environment for UCM views as well. I'll be sure to let you know when we do
      release it, though.

      A.

      On Tue, May 12, 2009 at 6:09 AM, Weden Jason-RWC467 <jweden@motorola.com> wrote:

      Hi Andrew,

      Thanks for your work on the clearcase hudson plugin. In researching a major
      problem today, I have found that the plugin doesn't react correctly to a
      config_spec change. It seems you are already aware of this as per the wiki:

      Next minor release in development
      Either 0.8.5 or 0.9 - unsure yet.
      Based on 0.8.4 codebase.
      Besides any bugfixes that come in, we intend to fix the behavior when a "Use
      update" job's config spec and/or load rules change. Currently, that means the
      view gets removed and recreated, but that will be changed to just use setcs/update.
      Do you have an ETA on this release yet? Thanks.

      Regards,

      Jason Weden
      FTTP AXSVision Software Development
      Access Networks, Home and Networks Mobility
      Motorola, Inc.
      978-614-3182

      Attachments

        Activity

          abayer Andrew Bayer added a comment -

          I've figured out how to change the base ClearCase snapshot checkout logic to fit
          this, but I'm stymied on the UCM use case.

          The current UCM logic is, if "Use update" is selected and the view path already
          exists, the plugin reads in the view's config spec, extracts the load rules from
          it, and compares the list of load rules defined for the job to see if each of
          those are present in the view's live load rules. If any of the configured load
          rules aren't in the view's load rules, the view is removed and recreated. Then,
          regardless of any of that, "cleartool update -force -log NUL -add_loadrules
          (load rule)" is called for each load rule configured for the job.

          So, as far as I can tell, the plugin is never checking to see if it should be
          updating the config spec - if it happens to encounter a load rule defined for
          the job that isn't in the view already, it'll end up getting a new config spec
          in the process of nuking/recreating the view, but that's the only way to get
          config spec changes with "Use update" selected. And if load rules were removed
          from the job configuration with no new ones added, those old, defunct load rules
          will actually still be present in the view, just not updated.

          So I can barely get my head around the current workflow - I honestly have no
          idea what the right workflow should be for UCM views with "Use update" where
          we're not removing the view every time anything changes. So if you have any
          suggestions/advice on that, I'd greatly appreciate it. =)

          abayer Andrew Bayer added a comment - I've figured out how to change the base ClearCase snapshot checkout logic to fit this, but I'm stymied on the UCM use case. The current UCM logic is, if "Use update" is selected and the view path already exists, the plugin reads in the view's config spec, extracts the load rules from it, and compares the list of load rules defined for the job to see if each of those are present in the view's live load rules. If any of the configured load rules aren't in the view's load rules, the view is removed and recreated. Then, regardless of any of that, "cleartool update -force -log NUL -add_loadrules (load rule)" is called for each load rule configured for the job. So, as far as I can tell, the plugin is never checking to see if it should be updating the config spec - if it happens to encounter a load rule defined for the job that isn't in the view already, it'll end up getting a new config spec in the process of nuking/recreating the view, but that's the only way to get config spec changes with "Use update" selected. And if load rules were removed from the job configuration with no new ones added, those old, defunct load rules will actually still be present in the view, just not updated. So I can barely get my head around the current workflow - I honestly have no idea what the right workflow should be for UCM views with "Use update" where we're not removing the view every time anything changes. So if you have any suggestions/advice on that, I'd greatly appreciate it. =)

          Code changed in hudson
          User: : abayer
          Path:
          trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/action/SnapshotCheckoutAction.java
          trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/action/UcmSnapshotCheckoutAction.java
          trunk/hudson/plugins/clearcase/src/test/java/hudson/plugins/clearcase/action/SnapshotCheckoutActionTest.java
          trunk/hudson/plugins/clearcase/src/test/java/hudson/plugins/clearcase/action/UcmSnapshotCheckoutActionTest.java
          http://fisheye4.cenqua.com/changelog/hudson/?cs=18217
          Log:
          [FIXED JENKINS-3672] When "Use update" is selected, we now update the config spec of the view when it changes (or when load rules change, for UCM) rather than removing and recreating the view.

          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/action/SnapshotCheckoutAction.java trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/action/UcmSnapshotCheckoutAction.java trunk/hudson/plugins/clearcase/src/test/java/hudson/plugins/clearcase/action/SnapshotCheckoutActionTest.java trunk/hudson/plugins/clearcase/src/test/java/hudson/plugins/clearcase/action/UcmSnapshotCheckoutActionTest.java http://fisheye4.cenqua.com/changelog/hudson/?cs=18217 Log: [FIXED JENKINS-3672] When "Use update" is selected, we now update the config spec of the view when it changes (or when load rules change, for UCM) rather than removing and recreating the view.

          People

            abayer Andrew Bayer
            jweden jweden
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: