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

Add Pipeline Support for ArtifactDeployer

    Details

    • Similar Issues:

      Description

      Since Jenkins 2.0 we are moving our Freestyle Builds to Pipelines, it would be nice to have Pipeline support in the ArtifactDeployer to not do this manually.

        Attachments

          Activity

          Hide
          cchapman Clint Chapman added a comment -

          Is there a workaround for using this plugin in pipeline without native support?

          Show
          cchapman Clint Chapman added a comment - Is there a workaround for using this plugin in pipeline without native support?
          Hide
          jovandeginste Jo Vandeginste added a comment - - edited

          Only by re-implementing the functionality (what I did for our projects); basically I run:

          mvn deploy:deploy-file -f ${deployPomFile} -DpomFile=${deployPomFile} \
              -Dfile=${file} -DrepositoryId=${remoteRepository} \
              -Durl=sftp://${remoteUploadUser}@${remoteServer}:${remoteLocation}
          

          Where:

          • deployPomFile: the (self-generated) pom.xml containing extra information about the target server + wagon-ssh
          • file: the jar or war file to be published
          • remoteRepository: the ID of the repository (as found in settings.xml and/or pom.xml)
          • remoteUploadUser, remoteServer, remoteLocation: the remote (ssh/sftp) user, server and root directory where the artifact should be uploaded to

          Basically I write a second pom.xml with the relevant information from the real pom.xml (modelVersion, groupId, artifactId, version, packaging) and use this template (to support uploading via ssh/sftp/scp):

          <?xml version="1.0" encoding="UTF-8"?>
          <project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="http://maven.apache.org/POM/4.0.0"
            xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
          
            <modelVersion>${modelVersion}</modelVersion>
            <groupId>${groupId}</groupId>
            <artifactId>${artifactId}</artifactId>
            <version>${version}</version>
            <packaging>${packaging}</packaging>
          
            <build>
              <extensions>
                <extension>
                  <groupId>org.apache.maven.wagon</groupId>
                  <artifactId>wagon-ssh</artifactId>
                  <version>2.10</version>
                </extension>
              </extensions>
            </build>
          </project>
          

          There is probably a cleaner way to do this, but the Jenkins sandbox is limiting

          Show
          jovandeginste Jo Vandeginste added a comment - - edited Only by re-implementing the functionality (what I did for our projects); basically I run: mvn deploy:deploy-file -f ${deployPomFile} -DpomFile=${deployPomFile} \ -Dfile=${file} -DrepositoryId=${remoteRepository} \ -Durl=sftp: //${remoteUploadUser}@${remoteServer}:${remoteLocation} Where: deployPomFile: the (self-generated) pom.xml containing extra information about the target server + wagon-ssh file: the jar or war file to be published remoteRepository: the ID of the repository (as found in settings.xml and/or pom.xml) remoteUploadUser, remoteServer, remoteLocation: the remote (ssh/sftp) user, server and root directory where the artifact should be uploaded to Basically I write a second pom.xml with the relevant information from the real pom.xml (modelVersion, groupId, artifactId, version, packaging) and use this template (to support uploading via ssh/sftp/scp): <?xml version= "1.0" encoding= "UTF-8" ?> <project xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns= "http://maven.apache.org/POM/4.0.0" xsi:schemaLocation= "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" > <modelVersion> ${modelVersion} </modelVersion> <groupId> ${groupId} </groupId> <artifactId> ${artifactId} </artifactId> <version> ${version} </version> <packaging> ${packaging} </packaging> <build> <extensions> <extension> <groupId> org.apache.maven.wagon </groupId> <artifactId> wagon-ssh </artifactId> <version> 2.10 </version> </extension> </extensions> </build> </project> There is probably a cleaner way to do this, but the Jenkins sandbox is limiting
          Hide
          cchapman Clint Chapman added a comment -

          Thanks Jo. Not quite as straight-forward as I'd like... We just want to deploy .NET projects to a file share and have them show up as artifacts on the job.

          Not sure if you're aware but I believe pipeline global libraries are automatically approved and avoid sandboxing.

          Thanks again

          Show
          cchapman Clint Chapman added a comment - Thanks Jo. Not quite as straight-forward as I'd like... We just want to deploy .NET projects to a file share and have them show up as artifacts on the job. Not sure if you're aware but I believe pipeline global libraries are automatically approved and avoid sandboxing. Thanks again
          Hide
          jovandeginste Jo Vandeginste added a comment -

          I'm aware, but we hit this: https://issues.jenkins-ci.org/browse/JENKINS-38272

          (Also, I clearly assumed you were talking about maven repo's, so my workaround is probably not that useful for you ...)

          Show
          jovandeginste Jo Vandeginste added a comment - I'm aware, but we hit this: https://issues.jenkins-ci.org/browse/JENKINS-38272 (Also, I clearly assumed you were talking about maven repo's, so my workaround is probably not that useful for you ...)
          Hide
          cchapman Clint Chapman added a comment -

          I obviously haven't used it yet. That is a problem. Thanks for the pointer.

          Show
          cchapman Clint Chapman added a comment - I obviously haven't used it yet. That is a problem. Thanks for the pointer.
          Hide
          jedavis Jason Davis added a comment -

          Just trying to understand, it sounds like there currently isn't a way to post to remote shares and still build the "Last Successful Deployed Artifacts" link in the Jenkins job pages with the plugin. Is that true?

          For me, very few of the jobs utilize maven and everyone I support is used to seeing remote artifacts deployed in the Freestyle jobs and then downloading artifacts using the "Last Successful Deployed Artifacts" links the plugin creates in the Job pages. If I can't replicate that in a pipeline, this becomes a blocker, because I can't convert the jobs from Freestyle ones. I really don't want to use the built-in Archive the Artifacts" step, because this plugin's great advantage over that feature, is that big installers, etc. can be posted to a separate server and not on the Jenkins master which for me will seriously increase the storage/backup requirements for the master.

          Show
          jedavis Jason Davis added a comment - Just trying to understand, it sounds like there currently isn't a way to post to remote shares and still build the "Last Successful Deployed Artifacts" link in the Jenkins job pages with the plugin. Is that true? For me, very few of the jobs utilize maven and everyone I support is used to seeing remote artifacts deployed in the Freestyle jobs and then downloading artifacts using the "Last Successful Deployed Artifacts" links the plugin creates in the Job pages. If I can't replicate that in a pipeline, this becomes a blocker, because I can't convert the jobs from Freestyle ones. I really don't want to use the built-in Archive the Artifacts" step, because this plugin's great advantage over that feature, is that big installers, etc. can be posted to a separate server and not on the Jenkins master which for me will seriously increase the storage/backup requirements for the master.
          Hide
          w60001 Christopher Shannon added a comment -

          Can anyone comment if we can reasonably expect this issue to be resolved anytime soon?  As we move from freestyle jobs to pipelines, this is a big pain point for us as well...

          Show
          w60001 Christopher Shannon added a comment - Can anyone comment if we can reasonably expect this issue to be resolved anytime soon?  As we move from freestyle jobs to pipelines, this is a big pain point for us as well...
          Hide
          rlogiacco Roberto Lo Giacco added a comment -

          Has anybody found a workaround for this? I'm about to abandon pipelines, mostly because I couldn't find an easy way to deploy to tomcat. I'm willing to use Generic Build Step, but it doesn't seem to work...

          Show
          rlogiacco Roberto Lo Giacco added a comment - Has anybody found a workaround for this? I'm about to abandon pipelines, mostly because I couldn't find an easy way to deploy to tomcat. I'm willing to use Generic Build Step, but it doesn't seem to work...

            People

            • Assignee:
              gbois Gregory Boissinot
              Reporter:
              mvollmer Marc Vollmer
            • Votes:
              10 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated: