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

ability to have hudson to deploy the artifacts from a successful build

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      It would be nice if hudson could deploy the artifacts from a successful build.
      For example, let's assume that there is a nightly build scheduled running "mvn
      install". We decide that we would like to deploy the build once a week.
      Hudson runs a successful build of the project and we decide that we should use
      that revision to deploy. We could simply checkout that revision and run "mvn
      deploy". However, since hudson already built these artifacts it would be nice
      to just tell hudson to do a "maven deploy" for hudson build number "10".

        Attachments

          Activity

          Hide
          stephenconnolly Stephen Connolly added a comment -

          It's not that simple!<br />

          Here's the rub,<br />

          <code>mvn install</code> runs all the attached plugins upto and including the
          install phase.<br />

          <code>mvn deploy</code> runs all the attached plugins upto and including the
          deploy phase.<br />

          What you want is to do a <code>mvn install</code> and if it succeeds, then do a
          <code>mvn (install,deploy]</code> (which does not exist). The problem here is
          that these are two separate invocations of maven and it has nowhere to persist
          state inbetween. <br />

          What is wrong with having a second project that once a week just runs <code>mvn
          deploy</code>??? If the install phase fails, then the deploy phase will never
          fire. <br />

          I hear somebody saying (but I want some control over deployment) Which brings
          us to <a
          href="https://hudson.dev.java.net/issues/show_bug.cgi?id=429">ISSUE-429</a>
          which, once implemented, should do exactly what you should be after <br />

          On the other hand, you could write an maven2 aggregator plugin (note to self:
          need to raise an issue on aggregator plugin support in maven2 projects) that
          attaches to the install phase and runs some pre-deploy sanity checks to block
          deploying all sub-modules if your santity checks fail.

          Show
          stephenconnolly Stephen Connolly added a comment - It's not that simple!<br /> Here's the rub,<br /> <code>mvn install</code> runs all the attached plugins upto and including the install phase.<br /> <code>mvn deploy</code> runs all the attached plugins upto and including the deploy phase.<br /> What you want is to do a <code>mvn install</code> and if it succeeds, then do a <code>mvn (install,deploy]</code> (which does not exist). The problem here is that these are two separate invocations of maven and it has nowhere to persist state inbetween. <br /> What is wrong with having a second project that once a week just runs <code>mvn deploy</code>??? If the install phase fails, then the deploy phase will never fire. <br /> I hear somebody saying (but I want some control over deployment) Which brings us to <a href="https://hudson.dev.java.net/issues/show_bug.cgi?id=429">ISSUE-429</a> which, once implemented, should do exactly what you should be after <br /> On the other hand, you could write an maven2 aggregator plugin (note to self: need to raise an issue on aggregator plugin support in maven2 projects) that attaches to the install phase and runs some pre-deploy sanity checks to block deploying all sub-modules if your santity checks fail.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          I agree that this is not very trivial to implement, but I'm very sympathetic to
          the use case — the key is the human intelligence in deciding which version to
          deploy.

          I'd imagine it should be possible to snapshot the state by capturing just few
          things, such as artifacts. With this, invoking additional goals (or even phases)
          might not be that hard.

          Doing this just for the default deploy target should be even easier, although
          doing this in a general way allows this to be used in other situations.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - I agree that this is not very trivial to implement, but I'm very sympathetic to the use case — the key is the human intelligence in deciding which version to deploy. I'd imagine it should be possible to snapshot the state by capturing just few things, such as artifacts. With this, invoking additional goals (or even phases) might not be that hard. Doing this just for the default deploy target should be even easier, although doing this in a general way allows this to be used in other situations.
          Hide
          jasonchaffee Jason Chaffee added a comment -

          I too agree that it is non-trivial using maven because of what I consider
          maven's poor implementation. However, my thought was to not use maven to deploy
          it. Instead, configure hudson with the correct information to be able to deploy
          as maven would and hudson could also modify the metadata file using some of
          maven's components. Therefore, maven would be taken out of the picture.

          Basically, hudson will run "mvn install" and keep these builds and fingerprints.
          Then, someone can pick a particular build number in hudson and tell hudson to
          "deploy" that build to the configured maven repo.

          Show
          jasonchaffee Jason Chaffee added a comment - I too agree that it is non-trivial using maven because of what I consider maven's poor implementation. However, my thought was to not use maven to deploy it. Instead, configure hudson with the correct information to be able to deploy as maven would and hudson could also modify the metadata file using some of maven's components. Therefore, maven would be taken out of the picture. Basically, hudson will run "mvn install" and keep these builds and fingerprints. Then, someone can pick a particular build number in hudson and tell hudson to "deploy" that build to the configured maven repo.
          Hide
          jasonchaffee Jason Chaffee added a comment -

          Will the build-promotion plugin address this bug?

          Show
          jasonchaffee Jason Chaffee added a comment - Will the build-promotion plugin address this bug?
          Hide
          huybrechts huybrechts added a comment -

          This might not be that hard to implement without rebuilding from source:

          • instead of running 'mvn install', run 'mvn deploy
            -DaltDeploymentRepository=...' to deploy to a staging repository (you should use
            a separate one per build)
          • for promotion, use the maven-staging-plugin to deploy your entire staging
            repository to a remote repository (only scp: supported).
          Show
          huybrechts huybrechts added a comment - This might not be that hard to implement without rebuilding from source: instead of running 'mvn install', run 'mvn deploy -DaltDeploymentRepository=...' to deploy to a staging repository (you should use a separate one per build) for promotion, use the maven-staging-plugin to deploy your entire staging repository to a remote repository (only scp: supported).
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Implemented in 1.191.

          As Jason noted, the real benefit of this is doing this from the promoted-builds
          plugin, so that you can deploy artifacts after some non-trivial tests have passed.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Implemented in 1.191. As Jason noted, the real benefit of this is doing this from the promoted-builds plugin, so that you can deploy artifacts after some non-trivial tests have passed.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            jasonchaffee Jason Chaffee
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: