I know this question has been asked already, but no details were given, and no answers have been provided. This is why I decided to create a question with some more details. I have my Jenkins 2.289.2 running on a Linux VM (Ubuntu 18.04.5 LTS). I create a new .NET Core ASP.NET web API project with the React template. Furthermore, I added a Jenkinsfile to the repository with the following content:
node{
stage('Clean and checkout'){
cleanWs()
checkout scm
}
stage('Restore'){
sh 'dotnet restore src/TestProject.sln'
}
stage('Clean'){
sh 'dotnet clean src/TestProject.sln'
}
stage('Build'){
sh 'dotnet build src/TestProject.sln --configuration Release'
}
}
Restore and Clean work just fine, but dotnet build fails with:
/usr/share/dotnet/sdk/3.1.411/Roslyn/Microsoft.CSharp.Core.targets(70,5): error MSB3883: Unerwartete Ausnahme: [/var/lib/jenkins/workspace/ols.TestProject_development/src/TestProject/TestProject.csproj]
/usr/share/dotnet/sdk/3.1.411/Roslyn/Microsoft.CSharp.Core.targets(70,5): error : System.ComponentModel.Win32Exception (11): Resource temporarily unavailable [/var/lib/jenkins/workspace/ols.TestProject_development/src/TestProject/TestProject.csproj]
Strange enough, if I use putty and navigate to /var/lib/jenkins/workspace/ols.TestProject_development and run dotnet build src/TestProject.sln --configuration Release it works just fine. It also works fine, if I create a Jenkins freestyle project with one shell build step:
dotnet restore src/TestProject.sln
dotnet clean src/TestProject.sln
dotnet build src/TestProject.sln --configuration Release
What I tried as well:
Installing dotnet core SDK 5.0 instead of 3.1
Using the Jenkins plugin .NET SDK Support and use:
dotnetBuild project: 'src/TestProject.sln'
Nothing worked, and I have no idea why it would fail as a pipeline build, but not as a freestyle project. Please help me guys.
It turned out to be an issue of my provider, STRATO. There linux v-server, which I used, caused the issue. It is also known that you cannot run microk8s on their servers. After changing to another v-server, the described Jenkins issue is gone.