Search

AdvancedBasic
1 of 2
Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-67450

dotnet sdk params

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Trivial Trivial
    • dotnet-sdk-plugin

      Hi.
      Thanks for this plugin, I find it very usefull. I use it on windows2019 core for legacy code compatability

      I have some suggestions for better expirience in declarative piplines:

      • Return exit code to pipline or variable: 
        Build error:

        Not failed pipline step(build failed by 'not found outputDir'):

        unstableIfWarnings  has pritty simmilar effect but not fails build
      • Set default encoding to UTF8 or make additional param for it:

      My current workaround use external library with powerhell with dotNet plugin kwargs in withDotnet block:

      //dotnetPublishPS.groovy
def call(Map config = [:]){
   def properties = ""
   config.properties.each{ k,v -> 
	properties += " -p:$k=$v"	
   } 
   return powershell(
     script: "dotnet publish -c:${config.configuration} ${properties}...etc...",
     encoding: 'UTF8',
     returnStatus: true
   )
}

       

        1. image-2021-12-24-12-13-29-581.png
          image-2021-12-24-12-13-29-581.png
          3 kB
        2. image-2021-12-24-12-13-59-290.png
          image-2021-12-24-12-13-59-290.png
          16 kB
        3. image-2021-12-24-12-34-28-376.png
          image-2021-12-24-12-34-28-376.png
          10 kB

          Tim Van Holder added a comment -

          These are three different issues, so probably should have gotten three different tickets.

          1. Currently, the plugin uses SimpleBuildStep so the same implementation supports both freestyle and pipeline builds.
            As far as I know, there is no way to return a value when using that interface.
            I would have to reimplement things so that there were true pipeline steps and then either duplicate things for freestyle, or have one call through to the other. Not impossible, but a lot of work (especially given that the return code is only ever 0 or 1, I believe).
          2. It's not clear to me what the issue here is. That doesn't sound like an error the plugin itself produces, and it sounds like a type of error that indicates a build failure. Can you give more detail on why you think the build should not have been marked as a failure there?
          3. This I can do; I currently use the character set assigned to the build (which on my system is UTF-8, but that may depend on the installation environment), but it's not unreasonable to make this configurable at the step level. On a windows node, I doubt it will make much difference (both msbuild.exe and dotnet.exe seem to emit ???? for non-latin characters in things like Obsolete messages).

          Tim Van Holder added a comment - These are three different issues, so probably should have gotten three different tickets. Currently, the plugin uses SimpleBuildStep so the same implementation supports both freestyle and pipeline builds. As far as I know, there is no way to return a value when using that interface. I would have to reimplement things so that there were true pipeline steps and then either duplicate things for freestyle, or have one call through to the other. Not impossible, but a lot of work (especially given that the return code is only ever 0 or 1, I believe). It's not clear to me what the issue here is. That doesn't sound like an error the plugin itself produces, and it sounds like a type of error that indicates a build failure. Can you give more detail on why you think the build should not have been marked as a failure there? This I can do; I currently use the character set assigned to the build (which on my system is UTF-8, but that may depend on the installation environment), but it's not unreasonable to make this configurable at the step level. On a windows node, I doubt it will make much difference (both msbuild.exe and dotnet.exe seem to emit ???? for non-latin characters in things like Obsolete messages).

          Viktor Sam added a comment -

          Hi.
          There are 2 issues not 3)
           unstableIfWarnings  has pritty simmilar effect but not fails build - its works as intended. I mention it becouse Exit Code: 1  may be handled by the same way

          There is non-latin custom exceptions in legacy code - they produce non readable characters. OS&msbuild&dotnet Has only english language packs and in their parts piece fine
          About encoding there is other workaround - set windows system encoding utf8. But it may be overkill

          Viktor Sam added a comment - Hi. There are 2 issues not 3)   unstableIfWarnings   has pritty simmilar effect but not fails build - its works as intended. I mention it becouse Exit Code: 1   may be handled by the same way There is non-latin custom exceptions in legacy code - they produce non readable characters. OS&msbuild&dotnet Has only english language packs and in their parts piece fine About encoding there is other workaround - set windows system encoding utf8. But it may be overkill

          Viktor Sam added a comment -

          Thank you! good job

          Viktor Sam added a comment - Thank you! good job

            zastai Tim Van Holder
            sam117 Viktor Sam
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: