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

Setting a tag in branch configuration breaks the check out

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Duplicate
    • Component/s: mercurial-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.466.1
      Mercurial 1.41
    • Similar Issues:

      Description

      if we use a tag in the branch configuration, it seems to break the check out. We use tags in our deployment steps, whereas a user would like to deploy a specific version (using maven). To do that, we need to check out a specific tag and run "mvn deploy" on it. This worked in 1.37 but it does not work in 1.41. We have backed the version of the plugin to get around this problem.

      Steps to reproduce:

      1. Create a free style job (any job type will do)
      2. Configure the mercurial plugin to clone a repository and instead of set a branch, set hg TAG on it
      3. Start the build

      Expected result:
      The code is checked out as it looked like when the tag was set

      Actual result:
      We get this error in the console

      Started by user anonymous
      Building on master in workspace /proj/hudson/home/project/jobs/some_job/workspace
      
      Deleting project workspace... done
      
      $ hg clone --rev rel-3.4.19.0 --noupdate /some/repo /proj/hudson/home/project/jobs/some_job/workspace
      adding changesets
      adding manifests
      adding file changes
      added 5311 changesets with 14365 changes to 3636 files
      [workspace] $ hg update --rev rel-3.4.19.0
      abort: unknown revision 'rel'!
      ERROR: Failed to update /some/repo to rev rel-3.4.19.0
      some_job is disabled. Triggering skipped
      Finished: FAILURE
      

        Attachments

          Issue Links

            Activity

            Hide
            patoarvizu Patricio Arvizu added a comment -

            I don't think that would work.

            Consider this case:

            • You created a branch "new-feature" off default.
            • Default is now two changesets ahead of the point where the branch was created.
            • Your "new-feature" branch added a couple of changesets and tagged the tip of the branch with "new-feature-v1".
            • Default and "new-feature" are unmerged.
            • Now your .hgtags in "new-feature" contains "new-feature-v1", but .hgtags on default doesn't contain that tag.
            • If Jenkins clones or pulls with 'hg <clone|pull> --rev default http://repository' it will only grab up to the tip of default and all it's predecessors. This would exclude "new-feature" (because they're unmerged).

            I believe an approach like this would work in Git but not in Mercurial.

            I think this fix would work. HOWEVER, one of the potential benefits of cloning only the specified branch is that you minimize the size of the repository (in terms of disk space), but maybe this could be an optional flag?

            Show
            patoarvizu Patricio Arvizu added a comment - I don't think that would work. Consider this case: You created a branch "new-feature" off default. Default is now two changesets ahead of the point where the branch was created. Your "new-feature" branch added a couple of changesets and tagged the tip of the branch with "new-feature-v1". Default and "new-feature" are unmerged. Now your .hgtags in "new-feature" contains "new-feature-v1", but .hgtags on default doesn't contain that tag. If Jenkins clones or pulls with 'hg <clone|pull> --rev default http://repository ' it will only grab up to the tip of default and all it's predecessors. This would exclude "new-feature" (because they're unmerged). I believe an approach like this would work in Git but not in Mercurial. I think this fix would work. HOWEVER, one of the potential benefits of cloning only the specified branch is that you minimize the size of the repository (in terms of disk space), but maybe this could be an optional flag?
            Hide
            domruf Dominik Ruf added a comment -

            I am thought of this scenario, but considered it not that common in the "real world".
            It is continues integration and tags are not that "continues" are they

            Of course I am aware that cloning the whole repo will cost more disk space
            But after think a bit more about this, my position now is, even if it is uncommon the repository should clone/pull the whole repo despite the disk usage. (disks are cheap)
            Building tags should work out of the box or you should explicitly mention in the description of the configuration option that tags won't work.

            Show
            domruf Dominik Ruf added a comment - I am thought of this scenario, but considered it not that common in the "real world". It is continues integration and tags are not that "continues" are they Of course I am aware that cloning the whole repo will cost more disk space But after think a bit more about this, my position now is, even if it is uncommon the repository should clone/pull the whole repo despite the disk usage. (disks are cheap) Building tags should work out of the box or you should explicitly mention in the description of the configuration option that tags won't work.
            Hide
            patoarvizu Patricio Arvizu added a comment -

            I agree that tags are not "continuous" but they serve another purpose that still applies in certain scenarios. I think they are still pretty common.

            I'm not clear on whether you think if this will be a good feature or not, though. Is your position now that your patch will fix this problem AND it will be valuable?

            Show
            patoarvizu Patricio Arvizu added a comment - I agree that tags are not "continuous" but they serve another purpose that still applies in certain scenarios. I think they are still pretty common. I'm not clear on whether you think if this will be a good feature or not, though. Is your position now that your patch will fix this problem AND it will be valuable?
            Hide
            domruf Dominik Ruf added a comment -

            I implemented an option to clone/pull the whole repo
            https://github.com/domruf/mercurial-plugin

            Show
            domruf Dominik Ruf added a comment - I implemented an option to clone/pull the whole repo https://github.com/domruf/mercurial-plugin
            Hide
            patoarvizu Patricio Arvizu added a comment -

            Awesome!

            Just remember to submit the pull request .

            By the way, I found this other pull request that has been there for about two years that tries to fix the same issue (https://github.com/jenkinsci/mercurial-plugin/pull/20). Let's see how your pull request goes

            Show
            patoarvizu Patricio Arvizu added a comment - Awesome! Just remember to submit the pull request . By the way, I found this other pull request that has been there for about two years that tries to fix the same issue ( https://github.com/jenkinsci/mercurial-plugin/pull/20 ). Let's see how your pull request goes

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                redsolo redsolo
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: