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

Provide option for cloning all branches with Mercurial SCM

    XMLWordPrintable

Details

    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

          davehunt Dave Hunt added a comment -

          This also affects triggering on changes, especially when we perform merges. If there's no change to the default (or specified) branch then the job is not triggered. We would like to trigger on changes to any branch.

          davehunt Dave Hunt added a comment - This also affects triggering on changes, especially when we perform merges. If there's no change to the default (or specified) branch then the job is not triggered. We would like to trigger on changes to any branch.
          jglick Jesse Glick added a comment -

          Are you sure you do not want to use the Multiple SCMs Plugin for this use case?

          jglick Jesse Glick added a comment - Are you sure you do not want to use the Multiple SCMs Plugin for this use case?
          whimboo Henrik Skupin added a comment -

          The Multiple SCM plugin exists to handle more than one repository. Also as expressed by the author different repositories should be checked out to their own subfolders to not cause conflicts. In our case we have only a single repository which contains named branches. Each branch contains tests for a specific version of the application under test. Some tests require a hotswap between those branches. Given that all branches of that given single repository have to be checked out. So we really miss the trigger as Dave mentioned.

          whimboo Henrik Skupin added a comment - The Multiple SCM plugin exists to handle more than one repository. Also as expressed by the author different repositories should be checked out to their own subfolders to not cause conflicts. In our case we have only a single repository which contains named branches. Each branch contains tests for a specific version of the application under test. Some tests require a hotswap between those branches. Given that all branches of that given single repository have to be checked out. So we really miss the trigger as Dave mentioned.
          jglick Jesse Glick added a comment -

          Dave's reported case sounds a lot like the caching feature built in to the plugin, which would not require a special job or Copy Artifact - you just configure your Hg installation to use caching, and then any job using a given public repo location will automatically share the cache (and slaves do not need to make the remote connection). If you are trying to do something more subtle, such as archiving particular snapshots of the repository, then I guess a freeform build step with hg clone -U would be suitable, but I am not sure what trigger to use; the Mercurial plugin is designed to maintain a checkout of a particular branch and poll for changes in it, which is a quite different use case. You would really want a custom build trigger which just looked for activity of any kind in a given repo.

          Henrik's case is different and probably suited to Multiple SCMs - place a checkout of each named branch in its own subdirectory of the workspace. Each branch will be polled for changes. That ought to work fine with the current Mercurial plugin unless I am missing something.

          jglick Jesse Glick added a comment - Dave's reported case sounds a lot like the caching feature built in to the plugin, which would not require a special job or Copy Artifact - you just configure your Hg installation to use caching, and then any job using a given public repo location will automatically share the cache (and slaves do not need to make the remote connection). If you are trying to do something more subtle, such as archiving particular snapshots of the repository, then I guess a freeform build step with hg clone -U would be suitable, but I am not sure what trigger to use; the Mercurial plugin is designed to maintain a checkout of a particular branch and poll for changes in it, which is a quite different use case. You would really want a custom build trigger which just looked for activity of any kind in a given repo. Henrik's case is different and probably suited to Multiple SCMs - place a checkout of each named branch in its own subdirectory of the workspace. Each branch will be polled for changes. That ought to work fine with the current Mercurial plugin unless I am missing something.
          whimboo Henrik Skupin added a comment -

          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.

          whimboo Henrik Skupin added a comment - 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.
          jglick Jesse Glick added a comment -

          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?

          jglick Jesse Glick added a comment - 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?
          igorkostenko 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.

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

          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.

          patoarvizu 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.
          jglick Jesse Glick added a comment -

          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 Jesse Glick added a comment - 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.

          People

            jglick Jesse Glick
            davehunt Dave Hunt
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: