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

Enable release to be performed from existing build

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • m2release-plugin
    • None

      It would be useful if a release could be performed using a "known-good" build, i.e. one that has been promoted or otherwise deemed to have passed additional quality gates. Starting a release by taking a new checkout from trunk/HEAD is somewhat hit and miss in volatile environments.

      Ideally an m2release could be triggered from the action of a build promotion, but I think this issue would need to be resolved before raising a change request on the promotion plugin.

          [JENKINS-7726] Enable release to be performed from existing build

          James Nord added a comment -

          Althoug this would be great we leverage the features of the maven-release-plugin to do the work for us.
          THis means that the modified (release) poms need to be checked in first before the tag is taken - so for the checkin to work you would need to be ad the head (for most SCMs).

          The only other way would be to branch first and then build from the branch - but then you don't get the latest head updated to the new development version.

          I can't see this coming at any time soon unless you wish to contribute a patch.

          James Nord added a comment - Althoug this would be great we leverage the features of the maven-release-plugin to do the work for us. THis means that the modified (release) poms need to be checked in first before the tag is taken - so for the checkin to work you would need to be ad the head (for most SCMs). The only other way would be to branch first and then build from the branch - but then you don't get the latest head updated to the new development version. I can't see this coming at any time soon unless you wish to contribute a patch.

          lynggaard added a comment -

          Could the following procedure be used:

          I have tested this manually using subversion

          1) C:\svn\testproj1_trunk> svn -m "create branch" cp svn://svn.example.net/forge/experiments/testproj1/trunk@5978 svn://svn.example.net/forge/experiments/testproj1/branches/tst-branch3 C:\svn\testproj1_branch
          2) svn co svn://svn.example.net/forge/experiments/testproj1/branches/tst-branch3
          3) C:\svn\testproj1_branch> mvn -Dusername=XXX -Dpassword=XXXX release:prepare
          4) C:\svn\testproj1_trunk> mvn -Dusername=XXX -Dpassword=XXXX release:update-versions
          (I left the branch in place in my tests)

          A few notes:

          • I haven't dealt with updating the scm information in the pom.xml on the branch. Which is one of the reasons I want to kill the branch so we don't leave incorrect information in the scm.
          • It seems that maven ignores the fact that the code is checked out from a branch when doing the release. So it does not complain about the scm information pointing to trunk, but it does update it correctly on the tag.
          • I tried using merging to get the updated version numbers back on trunk, but that gave me conflicts if there are changes in the pom files in revisions after the one performing the release from. This is the reason for using release:update-versions

          How feasible is it to integrate my idea ? I had a brief look at the code but could not really determine it.

          lynggaard added a comment - Could the following procedure be used: Just like the subversion release plugin ( http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Release+Manager ) let the user pick a build Perform a branch from that scm revision. Do a maven release from the branch. Do a release:update-versions on the trunk remove the branch I have tested this manually using subversion 1) C:\svn\testproj1_trunk> svn -m "create branch" cp svn://svn.example.net/forge/experiments/testproj1/trunk@5978 svn://svn.example.net/forge/experiments/testproj1/branches/tst-branch3 C:\svn\testproj1_branch 2) svn co svn://svn.example.net/forge/experiments/testproj1/branches/tst-branch3 3) C:\svn\testproj1_branch> mvn -Dusername=XXX -Dpassword=XXXX release:prepare 4) C:\svn\testproj1_trunk> mvn -Dusername=XXX -Dpassword=XXXX release:update-versions (I left the branch in place in my tests) A few notes: I haven't dealt with updating the scm information in the pom.xml on the branch. Which is one of the reasons I want to kill the branch so we don't leave incorrect information in the scm. It seems that maven ignores the fact that the code is checked out from a branch when doing the release. So it does not complain about the scm information pointing to trunk, but it does update it correctly on the tag. I tried using merging to get the updated version numbers back on trunk, but that gave me conflicts if there are changes in the pom files in revisions after the one performing the release from. This is the reason for using release:update-versions How feasible is it to integrate my idea ? I had a brief look at the code but could not really determine it.

          James Nord added a comment -

          Any funtionality needs to be SCM agnostic.

          using suitable values for suppressCommitBeforeTag and updateWorkingCopyVersions something may be able to be done, it would then need hudson to checkout the correct revision from the SCM.

          http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html

          James Nord added a comment - Any funtionality needs to be SCM agnostic. using suitable values for suppressCommitBeforeTag and updateWorkingCopyVersions something may be able to be done, it would then need hudson to checkout the correct revision from the SCM. http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html

            Unassigned Unassigned
            ddavison_uk ddavison_uk
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: