JenkinsPublishing Over SSH Pipelines

In many of the projects, things that seem very small or tiny come to be decisive factors to continue on the current path or to find a better one. Starting from simple text editors to tools that are used for a long period of time, we all have different flavors for each tool that comes in hand. Merging such ideas sometimes comes to be a to-do, and while this happens for any of the kind of work done in a group, there are also some other factors that help to shape the path to it.

In this blog we would like to address how we used Publish over SSH to achieve our needs.

The plugin has the following of the features:

• SCP - for sending files over SSH (SFTP)
• Executing commands on a remote server (can be disabled for a server configuration, or even for the whole plugin)
• Uses username and password (keyboard-interactive) or public key authentication
• Passwords/passphrases are being encrypted in the configuration files and in the UI
• SSH SFTP/ SSH Exec can be used for a build step during the build process (Freestyle and Matrix projects)
• Enable any command/ script to be executed in a pseudo TTY(since some commands are not allowed to run without TTY sessions)
• SSH before a (maven) project build, or to run after a build whether the build was a successful build or not 
• The plugin is also called "promotion aware" (send files directly from the artifacts directory of the build that is being promoted) 
• Optionally overrides the authentication credentials for each server in the job configuration (or provides them if they have not been provided for that server in the global configuration)
• Optionally retry again if the transfer of files fails (useful for flakey connections)

Our very first step will be to define what stages to use:

node {
  stage('Getting ready...') {
    git branch: "dev", credentialsId: 'your_id_on_jenkins', url: 'https://github.com/amenski/jenkins_pipeline.git'
  }

Building stage:

stage('Build'){
  script{
    try {
      if(isUnix()){
          sh 'mvn clean package'
      }else{
       bat 'mvn clean package'
      }
    } catch(err) {
    throw err
    }
   }
}

Let's assume that till this point everything is goning right.

stage('SSH transfer') {

 script {
  sshPublisher(
   continueOnError: false, failOnError: true,
   publishers: [
    sshPublisherDesc(
     configName: "${env.SSH_CONFIG_NAME}",
     verbose: true,
     transfers: [
      sshTransfer(
       sourceFiles: "${path_to_file}/${file_name}, ${path_to_file}/${file_name}",
       removePrefix: "${path_to_file}",
       remoteDirectory: "${remote_dir_path}",
       execCommand: "run commands after copy?"
   )
     ])
   ])
 }
}

In this block, we are having the sshPublisher keyword, which holds the different values corresponding to their respective keywords. By default, the plugin makes the build "UNSTABLE" if there are any errors. You can change this behavior by adding a feild FailOnError: true, which tells it to fail the job if there are any problems occuring. The publishers array holds details about where to send what and also some additional tuning parameters, including whether there is a command we need to issue after the files have been published on the server.

In the event that it is must to have more transfers or commands to issue, the sshTransferblock can be again used as:

transfers:[
  sshTransfer(
    execCommand: "Run commands before copy?"
   ),
  sshTransfer(
    sourceFiles:"${path_to_file}/${file_name}, ${path_to_file}/${file_name}",
    removePrefix: "${path_to_file}",
    remoteDirectory: "${remote_dir_path}",
    execCommand: "run commands after copy?"
  )
])

Deploy:

stage('Deploy'){
  if(currentBuild.currentResult == "SUCCESS" || currentBuild.currentResult == "UNSTABLE"){
    if (isUnix()) {
      sh 'echo "Build Succeded."'
      }else{
        bat 'echo "Build Succeded."'
      }
     }
    }
I must recommend that you use placeholders in every configuration related fields. It is much easier for upcoming changes. To accomplish this, you can use environment variables or parameters like in the above case and access them with "${env.VAR_NAME}" or "${params.VAR_NAME}".