Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-66120

Missing DOTNET_ROOT value breaks dotnet global tool usage on Linux

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • dotnet-sdk-plugin
    • None
    • CentOS 7, .NET SDK Support 1.1.1

      Installing and then attempting to use a .NET global tool (e.g., dotnet-reportgenerator-globaltool) with a dynamically installed .NET 5 setup fails. A simple reproduction:

      pipeline {
          agent {
              label 'centos' // this is a label for our CentOS 7 nodes
          }
          tools {
              dotnetsdk '5.0'
          }
          stages {
              stage('Test') {
                  steps {
                      sh '''
                          dotnet tool install dotnet-reportgenerator-globaltool --tool-path .'
                          reportgenerator -help
                      '''
                  }
              }
          }
      }
      

      This results in:

      + dotnet tool update dotnet-reportgenerator-globaltool --tool-path . 
      You can invoke the tool using the following command: reportgenerator
      Tool 'dotnet-reportgenerator-globaltool' (version '4.8.12') was successfully installed.
      + ./reportgenerator '-reports:**/*cobertura*.xml' -targetdir:MergedCoverage -reporttypes:Cobertura
      A fatal error occurred. The required library libhostfxr.so could not be found.
      ... etc. ...
      

      If I set `DOTNET_ROOT`, it works:

      pipeline {
          agent {
              label 'centos'
          }
          tools {
              dotnetsdk '5.0'
          }
          stages {
              stage('Test') {
                  steps {
                      sh '''
                          export DOTNET_ROOT=\$(dirname \$(realpath \$(which dotnet)))
                          dotnet tool install dotnet-reportgenerator-globaltool --tool-path .'
                          reportgenerator -help
                      '''
                  }
              }
          }
      }
      

      See https://github.com/dotnet/sdk/issues/12359 for background. It seems that this is an environment variable that this plugin should set when installing a .NET SDK.

          [JENKINS-66120] Missing DOTNET_ROOT value breaks dotnet global tool usage on Linux

          Interesting - I was not aware the .NET SDK had its own "JAVA_HOME" style variable.

          I was already setting DOTNET_SDK_JENKINS_TOOL_HOME to that path, so should be easy to set DOTNET_ROOT too.

          Tim Van Holder added a comment - Interesting - I was not aware the .NET SDK had its own "JAVA_HOME" style variable. I was already setting DOTNET_SDK_JENKINS_TOOL_HOME to that path, so should be easy to set DOTNET_ROOT too.

          Incidentally, if I added specific steps for dotnet tool commands (e.g. something like dotnetToolInstall 'dotnet-reportgenerator-globaltool', toolPath: '.'), would you be inclined to use them, or would you stick to shell/batch/... steps and run dotnet yourself?

          Tim Van Holder added a comment - Incidentally, if I added specific steps for dotnet tool commands (e.g. something like dotnetToolInstall 'dotnet-reportgenerator-globaltool', toolPath: '.' ), would you be inclined to use them, or would you stick to shell/batch/... steps and run dotnet yourself?

          Nick Jones added a comment - - edited

          I might use such a command if it existed, although I already have a dotnet command (in an internal shared library) that abstracts away the sh/bat/… details to allow cross-platform invocations, so using my own dotnet('tool install', etc.) would be comparable. The tool installation in question here is in fact already inside another command from that same library; I just skipped that detail here to make the repro simpler.

          Nick Jones added a comment - - edited I might use such a command if it existed, although I already have a dotnet command (in an internal shared library) that abstracts away the sh/bat/… details to allow cross-platform invocations, so using my own dotnet('tool install', etc.) would be comparable. The tool installation in question here is in fact already inside another command from that same library; I just skipped that detail here to make the repro simpler.

          Ok, just trying to gauge usefulness; with a tool you will need a step that runs it anyway, I suppose.

          It's unfortunate that the powershell support in Jenkins is spread across multiple places/plugins. I tried to add dynamic installs there, the way this plugin does for .NET SDKs, but ran into issues (it seemed to end up ignoring the updated path and just running the system powershell). Otherwise,

          {pwsh}

          steps could be used across the board, regardless of platform.

          Tim Van Holder added a comment - Ok, just trying to gauge usefulness; with a tool you will need a step that runs it anyway, I suppose. It's unfortunate that the powershell support in Jenkins is spread across multiple places/plugins. I tried to add dynamic installs there, the way this plugin does for .NET SDKs, but ran into issues (it seemed to end up ignoring the updated path and just running the system powershell). Otherwise, {pwsh} steps could be used across the board, regardless of platform.

          Reproduced using WSL on Windows; fix created and merged. Will push out a 1.1.2 soon.

          Tim Van Holder added a comment - Reproduced using WSL on Windows; fix created and merged. Will push out a 1.1.2 soon.

          Release created; will probably take a bit for it to propagate to the plugin site and the update center.

          Tim Van Holder added a comment - Release created; will probably take a bit for it to propagate to the plugin site and the update center.

            zastai Tim Van Holder
            medianick Nick Jones
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: