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

Performing a Maven release with Hudson Mercurial Plugin fails when trying to push to remote repository

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Major Major
    • m2release-plugin
    • None
    • Windows 7

      I'm trying to perform a Maven release on my project with Hudson Mercurial Plugin. I have a local Mercurial repository and I'm pushing my changes to a remote repository for Hudson to poll them.

      My hudson job configuration looks as follows:

      Mercurial Repository URL: http://repo (path to the remote repository)
      Mercurial Repository Browser: hgweb
      Maven release build release goals and options: -Dresume=false release:prepare release:perform

      For reference I have the following in my pom.xml:
      <scm>
      <connection>scm:hg:http://repo</connection>
      <developerConnection>scm:hg:http://repo</developerConnection>
      </scm>

      All regular (i.e. non-release builds) are performing succesfully. Hudson detects changes in the remote repository and performs "hg update". When I perform a Maven Release using the Hudson Maven Release Plug-In Plug-In, it's executing "hg status", "hg commit" and "hg push http://repo". The last command fails with the following message:

      [INFO] EXECUTING: cmd.exe /X /C "hg push http://repo"
      [ERROR]
      EXECUTION FAILED
      Execution of cmd : push failed with exit code: 1.
      Working directory was:
      C:\hudson\jobs\MyProject\workspace
      Your Hg installation seems to be valid and complete.
      Hg version: 1.5.1 (OK)

      I found out that I can workaround this problem by creating an additional remote repository on the same server and point the SCM connection strings in my pom.xml to that new repository. When I do it like that it runs without error. Only thing is, I don't want to have two remote repositories for each project and I want my SNAPSHOT version to be automatically updated (like I have with SVN).

          [JENKINS-6426] Performing a Maven release with Hudson Mercurial Plugin fails when trying to push to remote repository

          The error diagnostics on stdout gave me the following message:

          abort: push creates new remote heads on branch 'default'!

          I figured that this might have something to do with having uncommitted changes made by the Hudson Mercurial Plugin which prevents me from pushing. The output from "hg status" gave me:

          ? pom.xml.releaseBackup
          ? release.properties

          So, I added those files to my .hgignore file and committed. After I did this, I was able to push to the remote server. Now I can also perform Maven releases from Hudson without problems. Still I think this isn't a very neat solution. I also posted this on Hudson forums.

          jeroen_rosenberg added a comment - The error diagnostics on stdout gave me the following message: abort: push creates new remote heads on branch 'default'! I figured that this might have something to do with having uncommitted changes made by the Hudson Mercurial Plugin which prevents me from pushing. The output from "hg status" gave me: ? pom.xml.releaseBackup ? release.properties So, I added those files to my .hgignore file and committed. After I did this, I was able to push to the remote server. Now I can also perform Maven releases from Hudson without problems. Still I think this isn't a very neat solution. I also posted this on Hudson forums.

          Jesse Glick added a comment -

          Nothing to do with the Hudson Mercurial plugin that I can see. Assigning to the m2release plugin for evaluation, though I suspect your problem is not the fault of Hudson at all. Rather, a new changeset on the default branch simply appears on the server between the time the build started and the time you tried to run the release goal. maven-release-plugin is likely at fault; its Mercurial integration should not assume that mere 'hg push' will work to push the new tag changesets, since Mercurial does not by default allow you to push multiple heads to the same branch. (You can override this with --force if the server is not configured to prevent it, but then you risk confusing people who check out the repo since there will be no unambiguous tip of the default branch!) m-r-p could perhaps run 'hg fetch' before 'hg push', though this leaves the matter open to a race condition. (From other things I have seen online about m-r-p, I get the impression that it was designed for a centralized SCM like Subversion, and the Mercurial integration is not tested nearly as thoroughly.)

          Jesse Glick added a comment - Nothing to do with the Hudson Mercurial plugin that I can see. Assigning to the m2release plugin for evaluation, though I suspect your problem is not the fault of Hudson at all. Rather, a new changeset on the default branch simply appears on the server between the time the build started and the time you tried to run the release goal. maven-release-plugin is likely at fault; its Mercurial integration should not assume that mere 'hg push' will work to push the new tag changesets, since Mercurial does not by default allow you to push multiple heads to the same branch. (You can override this with --force if the server is not configured to prevent it, but then you risk confusing people who check out the repo since there will be no unambiguous tip of the default branch!) m-r-p could perhaps run 'hg fetch' before 'hg push', though this leaves the matter open to a race condition. (From other things I have seen online about m-r-p, I get the impression that it was designed for a centralized SCM like Subversion, and the Mercurial integration is not tested nearly as thoroughly.)

          James Nord added a comment -

          have you tried to reproduce this wothout hudson in the loop?

          1) checkout from the URL that hudson uses
          2) run mvn -B release:prepare release:perform

          I would suspect that this also fails as hudson is not involved after the initial checkout of the project sources and offloads the tagging and changing of POMs to the release plugin.

          James Nord added a comment - have you tried to reproduce this wothout hudson in the loop? 1) checkout from the URL that hudson uses 2) run mvn -B release:prepare release:perform I would suspect that this also fails as hudson is not involved after the initial checkout of the project sources and offloads the tagging and changing of POMs to the release plugin.

          James Nord added a comment -

          Closing as this is just the way that maven does releases.
          I would suggest seeing if this could be fixed in maven-release-plugin or the maven SCM Hg provider

          James Nord added a comment - Closing as this is just the way that maven does releases. I would suggest seeing if this could be fixed in maven-release-plugin or the maven SCM Hg provider

            Unassigned Unassigned
            jeroen_rosenberg jeroen_rosenberg
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: