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

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

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

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 ...)

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

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.

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...

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...