I don't think that there is much that the bat step can do about this. The bat and sh steps both assume that a non-zero error code indicates a failure and that a zero error code indicates success. Robocopy uses a zero error code to indicate that no files were copied but no error was detected . Robocopy uses error codes 1-7 to indicate various alternative success conditions.
Users of the bat step will need to return the error code and process it within their own Pipeline code. Here is an example of robocopy returning the error code 3 to indicate that files existed in the destination that are not in the source, By checking the return value of the bat step, it is not flagged as an error by the Jenkins job, since the caller then needs to decide if the error code indicates an error for their use case.
pipeline {
agent {
label 'windows'
}
stages {
stage('Hello') {
steps {
script {
def errcode = bat label: 'windows', returnStatus: true, script: '''
mkdir x
date > x\\date.old
mkdir y
date > y\\date.new
robocopy /MIR X Y'''
echo "Error code is ${errcode}"
}
}
}
}
}
Here is an example that resets the error code as was done in the original script. The reason the original script does not work is described in a stackoverflow article that explains what happens when set ERRORLEVEL=0 is run.
pipeline {
agent {
label 'windows'
}
stages {
stage('Hello') {
steps {
script {
def errcode = bat label: 'windows', returnStatus: true, script: '''
mkdir x
date > x\\date.old
mkdir y
date > y\\date.new
robocopy /MIR X Y
IF ERRORLEVEL LEQ 7 cmd /c exit 0
'''
echo "Error code is ${errcode}"
}
}
}
}
}
This seems to be related to durable task "bat" command, and not batch-task-plugin