| According to what I have read in the code UpdateUpdater should fallback to CheckoutUpdater in case of issues, which it does. But in the first analysis it seems the code checking the state of the working copy locks the WC database in case of the new working copy format (.svn/wc.db) A workaround is to use the CheckoutUpdater (verified) The issue looks as follows (for full stack see attachment):
Also: java.nio.file.FileSystemException: C:\Users\mwa\.jenkins\workspace\subversion\.svn\wc.db: The process cannot access the file because it is being used by another process.
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source)
at java.nio.file.Files.deleteIfExists(Unknown Source)
at jenkins.util.io.PathRemover.removeOrMakeRemovableThenRemove(PathRemover.java:237)
This can be replicated with this short Jenkinsfile script
pipeline {
agent any
stages {
stage('Corrupt database') {
steps {
script {
def file = '.svn/wc.db'
if (!fileExists(file)) {
writeFile(file: file, text: "invalid")
}
}
}
}
stage('Checkout') {
steps {
checkout([
$class: 'SubversionSCM',
additionalCredentials: [],
excludedCommitMessages: '',
excludedRegions: '',
excludedRevprop: '',
excludedUsers: '',
filterChangelog: false,
ignoreDirPropChanges: false,
includedRegions: '',
locations: [[cancelProcessOnExternalsFail: true,
credentialsId: '',
depthOption: 'infinity',
ignoreExternalsOption: true,
local: '.',
remote: 'file:///x']],
quietOperation: true,
workspaceUpdater: [$class: 'UpdateUpdater']
])
}
}
}
}
|
