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

Error "bzr: ERROR: No WorkingTree exists for" when using shared repositories without working trees and bzr checkout option

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: bazaar-plugin
    • Labels:
      None
    • Environment:
      Linux
    • Similar Issues:

      Description

      This may be a setup issue, but when running with a shared repository that has had the working trees removed I get the error message:
      bzr: ERROR: No WorkingTree exists for ...
      When I have the job configured to use checkout. It looks like the issue is that the plugin is issuing a command:
      "bzr update /path/to/repo"
      instead of just
      "bzr update"

        Attachments

          Activity

          Hide
          brook Brook Stevens added a comment -

          I am testing a fix where I just remove that line in the pull method which is working for me:
          args.add(getDescriptor().getBzrExe(),

          • verb,
          • source);
            + verb);

          There may be a more elegant solution as this wouldn't pick up new repository URLs. I could unbind and rebind on every update but would want some guidance on best approach as I am only looking at this plugin for the first time.

          Show
          brook Brook Stevens added a comment - I am testing a fix where I just remove that line in the pull method which is working for me: args.add(getDescriptor().getBzrExe(), verb, source); + verb); There may be a more elegant solution as this wouldn't pick up new repository URLs. I could unbind and rebind on every update but would want some guidance on best approach as I am only looking at this plugin for the first time.
          Hide
          sdirector Monty Taylor added a comment -

          Hrm. Unbind/rebind seems a little ugly, but it might be the right choice (we definitely don't want to be updating from old repo locations if the user has changed the config to point to a new location.) Perhaps we should check to see if the current bound location is the same as the config value?

          Show
          sdirector Monty Taylor added a comment - Hrm. Unbind/rebind seems a little ugly, but it might be the right choice (we definitely don't want to be updating from old repo locations if the user has changed the config to point to a new location.) Perhaps we should check to see if the current bound location is the same as the config value?
          Hide
          stewart Stewart Smith added a comment -

          I'm going to close this as not relevant for the current version as I've changed a whole bunch of code around that recently.

          Please reopen if there's still a problem.

          Show
          stewart Stewart Smith added a comment - I'm going to close this as not relevant for the current version as I've changed a whole bunch of code around that recently. Please reopen if there's still a problem.

            People

            • Assignee:
              stewart Stewart Smith
              Reporter:
              brook Brook Stevens
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: