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

POMs left in a modified state after failed release

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • m2release-plugin
    • None
    • Platform: HP, OS: Linux

      If the release plugin has run but the release failed, it leaves your POMs
      modified with the new version numbers. If your SCM uses update this will mean
      that subsequent builds (or releases) will see the modified version numbers.

      Apart from logging in and manually doing "svn revert", or just removing the
      workspace entirely, there is no easy way for a user to fix this after a failed
      release.

      Possibly this problem is related to the enhancement 3925.

          [JENKINS-4560] POMs left in a modified state after failed release

          stavanets added a comment -

          'Rollback goals' project config option has been added. If specified they will be invoked as maven goals if the release process fails. Attached the patch

          stavanets added a comment - 'Rollback goals' project config option has been added. If specified they will be invoked as maven goals if the release process fails. Attached the patch

          Alex Rovner added a comment -

          Was this patch released?

          Alex Rovner added a comment - Was this patch released?

          Anders Hammar added a comment -

          This is a fairly nasty issue! Imagine this scenario:

          • A Maven build job "mvn clan deploy" or similar, which will deploy a new snapshot version on every build. Not too uncommon I think.
          • If a release build fails, the next build triggered on a code change will actually deploy to the repo based on the failed release version number (as the modified pom is left in the workspace)! And it could some time until people notice this and understand what has happened.

          Anders Hammar added a comment - This is a fairly nasty issue! Imagine this scenario: A Maven build job "mvn clan deploy" or similar, which will deploy a new snapshot version on every build. Not too uncommon I think. If a release build fails, the next build triggered on a code change will actually deploy to the repo based on the failed release version number (as the modified pom is left in the workspace)! And it could some time until people notice this and understand what has happened.

          Anders Hammar added a comment -

          Figured out that if Subversion is used as scm, "Use 'svn update' as much as possible, with 'svn revert' before update" (or "Always check out a fresh copy") can be selected as check-out strategy as a workaround.

          Anders Hammar added a comment - Figured out that if Subversion is used as scm, "Use 'svn update' as much as possible, with 'svn revert' before update" (or "Always check out a fresh copy") can be selected as check-out strategy as a workaround.

            Unassigned Unassigned
            ben_kelley ben_kelley
            Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: