.netlinuxjenkins

Linux Jenkins Pipeline dotnet build fails as Pipeline, but not as Freestyle Project


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:

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.


Solution

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