Details
-
New Feature
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Won't Fix
Description
We're using the Mercurial SCM plugin to clone a repository so that it can be archived and made available to other jobs via the Copy Artifact plugin. We can't use the plugin directly from these subsequent jobs because they actually use two separate repositories, so we have two jobs that provide such artifacts.
The problem is that we need to clone all branches, and when leaving the branch empty the 'default' branch is cloned/pulled. It would be great if there was an option grab all branches. At the moment we are using a workaround of the 'hg pull' command as one of our build steps.
Attachments
Activity
The shell build step at the start of the job to run hg pull seems like the right solution for you then. Does this break anything?
Igor Kostenko
added a comment - That's how I do it - I'm using hg plugin to get data into fake directory (to get at least some changes in build description) and after that getting everything from hg manually. It's working but it's ugly hack - it will be much better if hg plugin could get everything.
Igor Kostenko
added a comment - That's how I do it - I'm using hg plugin to get data into fake directory (to get at least some changes in build description) and after that getting everything from hg manually. It's working but it's ugly hack - it will be much better if hg plugin could get everything. 
Patricio Arvizu
added a comment - I had been looking for this feature for a while and I discovered that the shared repository feature accomplishes what I wanted.
Normally, jobs using the mercurial plugin would first attempt to clone the repo with hg clone --rev [REV] <remote_repo> but now, it seems to attempt to clone the repo in the shared location or clone from it if it already exists.
With this, you no longer need to set up separate jobs to clone/build/package/etc. multiple branches. It also helps on a very specific corner case where Mercurial can't update to changesets tagged in a branch that's not the cloned one. This may be specific to my particular repository, and may not be a general use case, but it does help.
Now, on the other hand, I can understand how in certain cases, one might not want to share a repository and needs a full clone in the local workspace only, for instance if Jenkins is merging/committing code and it may collide with other jobs using the shared repo, so providing the option to clone all branches would help in that case.
Patricio Arvizu
added a comment - I had been looking for this feature for a while and I discovered that the shared repository feature accomplishes what I wanted.
Normally, jobs using the mercurial plugin would first attempt to clone the repo with hg clone --rev [REV] <remote_repo> but now, it seems to attempt to clone the repo in the shared location or clone from it if it already exists.
With this, you no longer need to set up separate jobs to clone/build/package/etc. multiple branches. It also helps on a very specific corner case where Mercurial can't update to changesets tagged in a branch that's not the cloned one. This may be specific to my particular repository, and may not be a general use case, but it does help.
Now, on the other hand, I can understand how in certain cases, one might not want to share a repository and needs a full clone in the local workspace only, for instance if Jenkins is merging/committing code and it may collide with other jobs using the shared repo, so providing the option to clone all branches would help in that case. After rereading the original request I think this is out of scope for the Mercurial plugin, which is designed around providing an SCM implementation with a checkout/update of a specific branch and a corresponding trigger/changelog/etc. What is being requested is really a distinct plugin, which may or may not want to depend on mercurial-plugin for some low-level functions: a Trigger combined with something else such as a Publisher which looks for any new changesets in a specified repository and produces a bundle as an artifact.
jglick, Dave and myself are working on the same project. So I have just added more details to our problem. As I have mentioned we can't have multiple subdirectories (checkouts) of the repository because the build process has to be able to do a hotswap between branches. That means all named branches of the local clone have to be up-to-date.