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

Support tags instead of branches

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When using a tag as the branch with mercurial, in some cases, the build will fail (example bellow).

      This is because the branch is used as a param to "hg incoming". Only the revisions up to the tagged one are pulled in the local clone. Since the tag is set in a changeset after the tagged revision itself, the tag name becomes unknown to the local clone -> The hg command that use the tag fails.

      The only solution I know is to avoid using "--rev" for the incoming command (same for pull).
      The drawback is that more changesets than needed will be retrieved, but at least we are sure to have the required ones.

      Example of log (TAG is set to "5.131-p18"):

      [Starform-6.0] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='

      {node}

      ' author='

      {author|xmlescape}

      ' rev='

      {rev}

      ' date='

      {date}

      '><msg>

      {desc|xmlescape}

      </msg><added>

      {file_adds|stringify|xmlescape}

      </added><deleted>

      {file_dels|stringify|xmlescape}

      </deleted><files>

      {files|stringify|xmlescape}

      </files><parents>

      {parents}

      </parents></changeset>\n" --rev ${TAG}
      [Starform-6.0] $ hg unbundle hg.bundle
      adding changesets
      adding manifests
      adding file changes
      added 12 changesets with 13 changes to 3 files (+1 heads)
      (run 'hg heads' to see heads, 'hg merge' to merge)
      [Starform-6.0] $ hg update --clean --rev ${TAG}
      abort: unknown revision '5.131-p18'!

      (jglick, I assigned you the issue since you seem to be maintaining the plugin)

        Attachments

          Issue Links

            Activity

            Hide
            cdevienne cdevienne added a comment -

            The problem is the same on the first build. The issued command is :

            hg clone --rev ${TAG}

            which has the same effect : only the tagged revision, and not the one containing the tags, is retrieved.

            I suggest :

            $ hg clone --noupdate REPO TARGET
            $ hg update --rev TAG

            Regards

            Christophe

            Show
            cdevienne cdevienne added a comment - The problem is the same on the first build. The issued command is : hg clone --rev ${TAG} which has the same effect : only the tagged revision, and not the one containing the tags, is retrieved. I suggest : $ hg clone --noupdate REPO TARGET $ hg update --rev TAG Regards Christophe
            Hide
            jglick Jesse Glick added a comment -

            This field was never intended for use with tags. Various aspects of the Hudson control flow make no sense if the revision is a tag; for example, changelog calculation and polling should probably be skipped entirely, since a tag is normally immutable once created.

            (Yes you can move a tag in Mercurial - but you would also need to decide on a branch holding the tag move commits. In other words, different branches can assign a tag of the same name to different revisions. Supporting such scenarios in the Hudson GUI is likely to be overkill when you can more easily run shell commands as part of the build to update your workspace to exactly what you want; changelogs and polling are what make this approach undesirable for regular situations.)

            Probably the user will have to indicate a tag in a separate field (mutually exclusive), or check a box saying that the branch field should be treated as a tag.

            Show
            jglick Jesse Glick added a comment - This field was never intended for use with tags. Various aspects of the Hudson control flow make no sense if the revision is a tag; for example, changelog calculation and polling should probably be skipped entirely, since a tag is normally immutable once created. (Yes you can move a tag in Mercurial - but you would also need to decide on a branch holding the tag move commits. In other words, different branches can assign a tag of the same name to different revisions. Supporting such scenarios in the Hudson GUI is likely to be overkill when you can more easily run shell commands as part of the build to update your workspace to exactly what you want; changelogs and polling are what make this approach undesirable for regular situations.) Probably the user will have to indicate a tag in a separate field (mutually exclusive), or check a box saying that the branch field should be treated as a tag.
            Hide
            cdevienne cdevienne added a comment -

            I get your point, and the behavior you propose makes sense. The changelog calculation should indeed be slipped entirely.

            As far a using shell commands as part of the build, the major problem is that hudson won't know what revision we actually build from. Moreover, it would require an additionnal pull since the tag might not be on the pulled branch.

            Do you think the solution you propose is easy to implement ? And when do you think it would be ready for use (if at all) ?

            Thanks,

            Christophe

            Show
            cdevienne cdevienne added a comment - I get your point, and the behavior you propose makes sense. The changelog calculation should indeed be slipped entirely. As far a using shell commands as part of the build, the major problem is that hudson won't know what revision we actually build from. Moreover, it would require an additionnal pull since the tag might not be on the pulled branch. Do you think the solution you propose is easy to implement ? And when do you think it would be ready for use (if at all) ? Thanks, Christophe
            Hide
            jglick Jesse Glick added a comment -

            I have no current plans to work on it.

            "Hudson won't know what revision we actually build from" - true but this ordinarily only matters for purposes of changelog display and polling, which would be disabled for a tag-based job anyway.

            "it would require an additional pull since the tag might not be on the pulled branch" - if this is the case then there is little hope of a GUI configuration working for you. You would need to write a shell script to the effect of:

            hg pull -r branch-which-defines-tags $remote
            hg up -c branch-which-defines-tags
            hg pull -r $desired-tag remote
            hg up -c desired-tag

            I do not know of any repository "in the wild" which uses this style, and it is not clear Mercurial even makes it possible. According to

            http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id384894

            "when Mercurial is parsing the tags in a repository, it never reads the working copy of the .hgtags file. Instead, it reads the most recently committed revision of the file."

            where by "most recently committed revision" I understand "tip". If you have multiple heads in the repository (such as multiple branches), then it is impractical to control what tip happens to be.

            In my experiments using Hg 1.4.2, the behavior is not even this; after adding a tag on one branch, and setting it (-f) to something else on another branch, the second definition is always used - even if the working copy is updated to the first branch, .hgtags has been more recently edited & committed on the first branch, and .hg/tags.cache has been deleted.

            Show
            jglick Jesse Glick added a comment - I have no current plans to work on it. "Hudson won't know what revision we actually build from" - true but this ordinarily only matters for purposes of changelog display and polling, which would be disabled for a tag-based job anyway. "it would require an additional pull since the tag might not be on the pulled branch" - if this is the case then there is little hope of a GUI configuration working for you. You would need to write a shell script to the effect of: hg pull -r branch-which-defines-tags $remote hg up -c branch-which-defines-tags hg pull -r $desired-tag remote hg up -c desired-tag I do not know of any repository "in the wild" which uses this style, and it is not clear Mercurial even makes it possible. According to http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id384894 "when Mercurial is parsing the tags in a repository, it never reads the working copy of the .hgtags file. Instead, it reads the most recently committed revision of the file." where by "most recently committed revision" I understand "tip". If you have multiple heads in the repository (such as multiple branches), then it is impractical to control what tip happens to be. In my experiments using Hg 1.4.2, the behavior is not even this; after adding a tag on one branch, and setting it (-f) to something else on another branch, the second definition is always used - even if the working copy is updated to the first branch, .hgtags has been more recently edited & committed on the first branch, and .hg/tags.cache has been deleted.
            Hide
            toddh toddh added a comment -

            This just started biting us as well and I wanted to add our use case in hope of getting a fix.

            We setup two projects in Hudson, development and release. Our development project polls the Mercurial repo and builds from tip. This project works fine as-is since no tags are involved. However, our release project is parameterized to build the tagged version.

            For some time now we've worked around the problem by including the variable in the repository URL like this:

            https://myrepo.com/mercurial/mysite/#${BUILD_LABEL}

            The problem with this approach is the Mercurial plug-in sees each build as a unique URL and does a full clone. That changes every file timestamp every time a build is performed. For our sites it's preferable to see different timestamps depending on when files were updated.

            I can get closer to the desired behavior by putting the parameter in the branch field but then I get the problem above. The best I've been able to do is pass a revision hash to the parameter in place of the tag associated with it. But that process is more error prone than communicating tag names.

            Hope all that makes sense. Thanks for your work on this plugin!

            Show
            toddh toddh added a comment - This just started biting us as well and I wanted to add our use case in hope of getting a fix. We setup two projects in Hudson, development and release. Our development project polls the Mercurial repo and builds from tip. This project works fine as-is since no tags are involved. However, our release project is parameterized to build the tagged version. For some time now we've worked around the problem by including the variable in the repository URL like this: https://myrepo.com/mercurial/mysite/#$ {BUILD_LABEL} The problem with this approach is the Mercurial plug-in sees each build as a unique URL and does a full clone. That changes every file timestamp every time a build is performed. For our sites it's preferable to see different timestamps depending on when files were updated. I can get closer to the desired behavior by putting the parameter in the branch field but then I get the problem above. The best I've been able to do is pass a revision hash to the parameter in place of the tag associated with it. But that process is more error prone than communicating tag names. Hope all that makes sense. Thanks for your work on this plugin!
            Hide
            jglick Jesse Glick added a comment -

            If the plugin is informed that the revision label is a tag and not a branch, it can probably handle the case of a movable tag made with tag -f (or a sequence of tags when using parameterized builds). pull -r $tagname && hg up -r $tagname (the usual idiom for branches) will not work since the tag cset will not be pulled; could either pull all incoming csets (from any branch!) and then update to the new tag, or pull -r $tagname and hg up tip and hope that works (but in the presence of multiple branches it might not). pull -b . && hg up -r $tagname might work reliably.

            Show
            jglick Jesse Glick added a comment - If the plugin is informed that the revision label is a tag and not a branch, it can probably handle the case of a movable tag made with tag -f (or a sequence of tags when using parameterized builds). pull -r $tagname && hg up -r $tagname (the usual idiom for branches) will not work since the tag cset will not be pulled; could either pull all incoming csets (from any branch!) and then update to the new tag, or pull -r $tagname and hg up tip and hope that works (but in the presence of multiple branches it might not). pull -b . && hg up -r $tagname might work reliably.
            Hide
            jglick Jesse Glick added a comment -

            Note that pull -b is only available in Hg 1.5 and later.

            Show
            jglick Jesse Glick added a comment - Note that pull -b is only available in Hg 1.5 and later.
            Hide
            ricktw Rick Oosterholt added a comment -

            Since this feature is still not implemented, I've found a work-around which works for me:

            Configure the 'default' Branch in the job and configure a 'windows command' or 'shell script' as first build step which executes: hg update -r TAGNAME

            Show
            ricktw Rick Oosterholt added a comment - Since this feature is still not implemented, I've found a work-around which works for me: Configure the 'default' Branch in the job and configure a 'windows command' or 'shell script' as first build step which executes: hg update -r TAGNAME
            Hide
            jakobmalm Jakob Malm added a comment -

            @ricktw A downside is that Jenkins won't record the correct changeset...

            Show
            jakobmalm Jakob Malm added a comment - @ricktw A downside is that Jenkins won't record the correct changeset...
            Hide
            mfiers Martin Fiers added a comment -

            This also affects us. There are many workarounds displayed here, but as discussed, they do not really give a nice solution.

            "Probably the user will have to indicate a tag in a separate field (mutually exclusive), or check a box saying that the branch field should be treated as a tag."

            This looks like a clean solution... So why not implement it for those that need it? (there's even blogs about possible ways to circumvent this problem, so I guess there's enough people that would benefit from it).

            The only thing that probably has to change in case this option is selected, is to remove the `cmd.add("--rev", branch);` line in main/java/hudson/plugins/mercurial/MercurialSCM.java on line 318.

            https://github.com/jenkinsci/mercurial-plugin/blob/master/src/main/java/hudson/plugins/mercurial/MercurialSCM.java#L321

            Unfortunately, trying to modify the code ourselves and installing the created hpi file manually messed up our jenkins installation.

            Show
            mfiers Martin Fiers added a comment - This also affects us. There are many workarounds displayed here, but as discussed, they do not really give a nice solution. "Probably the user will have to indicate a tag in a separate field (mutually exclusive), or check a box saying that the branch field should be treated as a tag." This looks like a clean solution... So why not implement it for those that need it? (there's even blogs about possible ways to circumvent this problem, so I guess there's enough people that would benefit from it). The only thing that probably has to change in case this option is selected, is to remove the `cmd.add("--rev", branch);` line in main/java/hudson/plugins/mercurial/MercurialSCM.java on line 318. https://github.com/jenkinsci/mercurial-plugin/blob/master/src/main/java/hudson/plugins/mercurial/MercurialSCM.java#L321 Unfortunately, trying to modify the code ourselves and installing the created hpi file manually messed up our jenkins installation.
            Hide
            jglick Jesse Glick added a comment -

            So why not implement it for those that need it?

            That is my plan. No time in October, hope to have more time in November.

            Show
            jglick Jesse Glick added a comment - So why not implement it for those that need it? That is my plan. No time in October, hope to have more time in November.
            Hide
            mienamoo Hermien Pellissier added a comment -

            Any news on this implementation yet? We also need this feature.

            Show
            mienamoo Hermien Pellissier added a comment - Any news on this implementation yet? We also need this feature.
            Hide
            jglick Jesse Glick added a comment -

            No time this week. Still on my list.

            Show
            jglick Jesse Glick added a comment - No time this week. Still on my list.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/java/hudson/plugins/mercurial/MercurialSCM.java
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/config.jelly
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/help-branch.html
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/help-revision.html
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/help-revisionType.html
            src/test/java/hudson/plugins/mercurial/SCMTestBase.java
            http://jenkins-ci.org/commit/mercurial-plugin/a1d636a76bbcd99a7ee11e6460da3c2240030d42
            Log:
            [FIXED JENKINS-5396] Added supported option to update to a tag rather than a branch.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/plugins/mercurial/MercurialSCM.java src/main/resources/hudson/plugins/mercurial/MercurialSCM/config.jelly src/main/resources/hudson/plugins/mercurial/MercurialSCM/help-branch.html src/main/resources/hudson/plugins/mercurial/MercurialSCM/help-revision.html src/main/resources/hudson/plugins/mercurial/MercurialSCM/help-revisionType.html src/test/java/hudson/plugins/mercurial/SCMTestBase.java http://jenkins-ci.org/commit/mercurial-plugin/a1d636a76bbcd99a7ee11e6460da3c2240030d42 Log: [FIXED JENKINS-5396] Added supported option to update to a tag rather than a branch.
            Hide
            mienamoo Hermien Pellissier added a comment -

            I installed the experimental plugin with this change, and it works beautifully. Thanks Jesse!

            Show
            mienamoo Hermien Pellissier added a comment - I installed the experimental plugin with this change, and it works beautifully. Thanks Jesse!
            Hide
            cowwoc cowwoc added a comment -

            (Confused) Is this fix part of the public plugin? Or is it not released to the public yet? Last time I checked I didn't see a separate "tag" UI field.

            Show
            cowwoc cowwoc added a comment - (Confused) Is this fix part of the public plugin? Or is it not released to the public yet? Last time I checked I didn't see a separate "tag" UI field.
            Hide
            jglick Jesse Glick added a comment -

            It is currently only on the experimental update center. I can push a general 1.50 release, though; probably about time.

            Show
            jglick Jesse Glick added a comment - It is currently only on the experimental update center. I can push a general 1.50 release, though; probably about time.

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                cdevienne cdevienne
              • Votes:
                15 Vote for this issue
                Watchers:
                19 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: