Jenkins plugin issue with .NET SDK location

Hi all,

We have a problem with a build using the Octopus Jenkins Plugin. The problem is about the location of the .NET SDK which is not found by the Octopus CLI tool. It’s not at the default location (/usr/share/dotnet) and for some reason the environment variable DOTNET_ROOT seems to have no effect even when it’s set.

I’ve simplified our pipeline as much as I could to this:

#!groovy
@Library('pipeline-library')_

pipeline {
    agent { label 'linux-slaves && dotnet' }
    environment {
        DOTNET_ROOT = "/opt/jenkins/tools/com.cloudbees.jenkins.plugins.customtools.CustomTool/dotnet-sdk-3.1/"
        PATH = "/opt/jenkins/tools/com.cloudbees.jenkins.plugins.customtools.CustomTool/dotnet-sdk-3.1/:$PATH"
    }
    stages {
       stage('Pack') {
            steps {
                script {
                    sh "printenv DOTNET_ROOT"
                    sh "dotnet --version"
                    sh "dotnet tool install --tool-path ./tools --add-source https://internal-artifactory-nuget-proxy Octopus.DotNet.Cli"
                    sh "./tools/dotnet-octo version"
                }
                octopusPack \
                    toolId: 'Default', \
                    packageId: "TestPackage", \
                    packageFormat: 'zip', \
                    sourcePath: './src/', \
                    outputPath: './artifacts', \
                    packageVersion: "1.0.0" \
            }
        }
    }
    post {
        cleanup {
            script {
                cleanWs()
            }
        }
    }
}

And this is the build log:

[Pipeline] sh
+ printenv DOTNET_ROOT
/opt/jenkins/tools/com.cloudbees.jenkins.plugins.customtools.CustomTool/dotnet-sdk-3.1/
[Pipeline] sh
+ dotnet --version
3.1.402
[Pipeline] sh
+ dotnet tool install --tool-path ./tools --add-source https://internal-artifactory-nuget-proxy Octopus.DotNet.Cli
You can invoke the tool using the following command: dotnet-octo
Tool 'octopus.dotnet.cli' (version '7.4.4') was successfully installed.
[Pipeline] sh
+ ./tools/dotnet-octo version
7.4.4
[Pipeline] }
[Pipeline] // script
[Pipeline] octopusPack
[ervice_feature_pipeline-test-tom] $ ./tools/dotnet-octo pack --id TestPackage --version 1.0.0 --format zip --basePath ./src/ --include ** --outFolder ./artifacts
A fatal error occurred. The required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/opt/jenkins/workspace/ervice_feature_pipeline-test-tom/tools/.store/octopus.dotnet.cli/7.4.4/octopus.dotnet.cli/7.4.4/tools/netcoreapp3.1/any/].
If this is a framework-dependent application, install the runtime in the global location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].

The .NET Core runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=rhel.7-x64
INFO: Octopus CLI exit code: 131
ERROR: Unable to create or deploy release. Please check the build log for details on the error.

As you can see, we first set the environment variable DOTNET_ROOT to the location where the .NET SDK is installed. It’s printed out with “printenv” and the installation of the CLI tool is successful. Even the execution of the tool “dotnet-octo” works, when calling it from the shell.

But now the CLI tool should be used by the plugin (octopusPack). So we configured it this way:

The tool is found, but it looks like the environment variable DOTNET_ROOT is not set for the plugin. Is this a bug within the plugin? Or did we miss a configuration?

Thank you for your help

Tom

Hi Thomas,
Thanks for reaching out and providing such great detail. First, let me apologize for the delay in getting back to you. I’m currently attempting to reproduce this behavior to confirm whether or not this is a bug.

Also, here’s a link to our Jenkins documentation, just if you haven’t seen it already.

Sorry I don’t have more insight for you, but I will get back to you shortly.
Thank you for your patients,
Tina

Hi Tina,

Thank you for your first hint. Yes, I’ve had a look at this. Actually we’d prefer the .NET Core Tool option over the Octopus CLI option as it fits much better to our existing pipeline. However, I’ve also tried the Octopus CLI for Linux (https://octopus.com/downloads/octopuscli#linux). I’ve downloaded and extracted it and it works fine. I suppose it’s because it’s a self-contained application that doesn’t need an installed .NET Core runtime. However the .NET Core Tool would be very handy, because we don’t have to care for updates and we can download it through our internal nuget proxy (we don’t have a direct internet connection from the build server).
Anyway, this is the current workaround we’re using and the reason the problem isn’t that urgent. But it would help us to have a more stable solution.

Thanks in advance

Tom

Hi Tom,
Thank you for this update and please accept my apologies for the delay in getting back to you. I’m glad you found a workaround for the moment. I did want to let you know that similar issues have come up for other Customers resulting in this GitHub Issue that may bring about a fix for this in the future. Feel free to subscribe to the GitHub issue to be notified of any updates.

I hope this helps. Don’t hesitate to reach out again if you have further questions.
Kind Regards,
Tina

Hi Tina
Sorry, now it’s me taking a long time to answer. Thanks for your reply. This is a good hint. Although it’s not exactly the same problem, the chance might be good that it’s fixed as well with this issue. I’ll subscribe to it and wait until it’s fixed. Thanks!
Kind regards,
Tom

1 Like