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

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.

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

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.

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!

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.

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

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

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.

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.

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

No time this week. Still on my list.

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.

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

(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.

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