Would allow for use from workflows.

          [JENKINS-25976] Make DeployPublisher a SimpleBuildStep

          Jesse Glick created issue -
          Patrick Wolf made changes -
          Epic Link New: JENKINS-34657 [ 170293 ]
          Daniel Beck made changes -
          Comment [ [~danielbeck] unless the code has changed the GET request does not actually trigger a build, rather it is a hint to Jenkins that there may be a change so go and run polling to see if there actually is a change.

          That is a subtle difference, as Jenkins is not trusting the GET request, rather it is trusting the polling of the git server.

          That at least was the design KK originally picked and the blog post was based on that design. I am not sure if the GET request has since been augmented in ways that supply contextual data that would not be available by polling. If so then that is a vulnerability, but the original design is only useful as a DoS attack of the git server ]

          Jesse Glick added a comment -

          amuniz says:

          The plugin codebase (on master) is not compiling with core baseline 1.480.1 (minimum required by Workflow). As a first step we have to make it compatible with the required core baseline.

          Compilation issue related with public interface FileCallable<T> extends Serializable, RoleSensitive extending RoleSensitive which requires an implementation of void checkRoles(RoleChecker checker).

          Resolving this compilation issues seems simple, just add the missing method, but I guess this could impact in the general runtime behavior of this plugin.

          Documentation: http://documentation.cloudbees.com/docs/dev-at-cloud/CloudBees+Deployer+Plugin+for+Continuous+Deployment.html

          Perhaps outdated.

          Finally, it seems that we don't have to change anything in cloudbees-deployer but in deployer-framework.

          tfennelly says:

          Tasks:

          1. (1d) AbstractProject to Job etc in deployer-framework-plugin
            • Current understanding is that we do not need to modify the cloudbees-deployer plugin
          2. (1d) Fix tests
          3. (1d) Automated tests specific to workflow
          4. (1d) Resolve TODOs, if any
          5. (1d) Backward Compatibility review (lots of method signatures have changed)
          6. (4h) Create and manage PR
          7. (4h) Release plugin
            • Release binaries
            • Docs (wiki etc)

          Jesse Glick added a comment - amuniz says: The plugin codebase (on master) is not compiling with core baseline 1.480.1 (minimum required by Workflow). As a first step we have to make it compatible with the required core baseline. Compilation issue related with public interface FileCallable<T> extends Serializable, RoleSensitive extending RoleSensitive which requires an implementation of void checkRoles(RoleChecker checker) . Resolving this compilation issues seems simple, just add the missing method, but I guess this could impact in the general runtime behavior of this plugin. Documentation: http://documentation.cloudbees.com/docs/dev-at-cloud/CloudBees+Deployer+Plugin+for+Continuous+Deployment.html Perhaps outdated. Finally, it seems that we don't have to change anything in cloudbees-deployer but in deployer-framework. tfennelly says: Tasks: (1d) AbstractProject to Job etc in deployer-framework-plugin Current understanding is that we do not need to modify the cloudbees-deployer plugin (1d) Fix tests (1d) Automated tests specific to workflow (1d) Resolve TODOs, if any (1d) Backward Compatibility review (lots of method signatures have changed) (4h) Create and manage PR (4h) Release plugin Release binaries Docs (wiki etc)
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 159964 ] New: JNJira + In-Review [ 180192 ]
          Andrew Bayer made changes -
          Labels Original: workflow New: pipeline workflow
          Andrew Bayer made changes -
          Labels Original: pipeline workflow New: pipeline

          Alex Johnson added a comment - - edited

          Discussed with svanoort briefly about need to confirm acceptance criteria, here is a start:

          1. Fix tests and add Pipeline tests 
          2. Update plugin version to 2.0+, fix findbugs and any javadoc errors
          3. Refactor to work with pipeline APIs
          4. Create pipeline Step that is configurable from pipeline
          5. Write unit tests that confirm new functionality
          6. Manually test that .war deploys from pipeline (preferably both Tomcat and Glassfish)

          I'm proposing the following syntax, I think this provides a reasonably straightforward use and config.

          node { 
              def tc8 = tomcat8( 
                  url:        'http://localhost:1234/app',
                  password:   '******', 
                  userName:   'admin'
              )
              deploy(container: tc8, war: '/target/app.war', contextPath: '/app')   
              deploy(containers: [tc8, gf3], war: '/target/app.war', contextPath: '/app')
          }

          I've already started addressing some of these in PR25 and PR26

          Alex Johnson added a comment - - edited Discussed with svanoort briefly about need to confirm acceptance criteria, here is a start: Fix tests and add Pipeline tests  Update plugin version to 2.0+, fix findbugs and any javadoc errors Refactor to work with pipeline APIs Create pipeline Step that is configurable from pipeline Write unit tests that confirm new functionality Manually test that .war deploys from pipeline (preferably both Tomcat and Glassfish) I'm proposing the following syntax, I think this provides a reasonably straightforward use and config. node { def tc8 = tomcat8( url: 'http: //localhost:1234/app' , password: '******' , userName: 'admin' ) deploy(container: tc8, war: '/target/app.war' , contextPath: '/app' ) deploy(containers: [tc8, gf3], war: '/target/app.war' , contextPath: '/app' ) } I've already started addressing some of these in PR25 and PR26 . 

          Sam Van Oort added a comment -

          alexbrjo Looks like a solid start – I'd add including a Dummy deploy implementation (at least) that verifies the step can run in pipeline, and at least a manual test that deployment runs cleanly in pipeline, preferably an automated one if it can be easily done (if not trivial, then manual would be okay). 

          Sam Van Oort added a comment - alexbrjo Looks like a solid start – I'd add including a Dummy deploy implementation (at least) that verifies the step can run in pipeline, and at least a manual test that deployment runs cleanly in pipeline, preferably an automated one if it can be easily done (if not trivial, then manual would be okay). 
          Alex Johnson made changes -
          Epic Link Original: JENKINS-34657 [ 170293 ] New: JENKINS-44690 [ 182554 ]

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: