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

Dot net SDK plugin shows too many option (.net build, etc.) in "add build steps" in the UI in free style job

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Minor Minor
    • dotnet-sdk-plugin
    • None

      Dot net SDK plugin shows too many option (.net build, etc.) in "add build steps" in the UI in free style job

       

      It should show one option for e.g. "dot net" in add build step and after adding it,  it should show the multiple options. That will remove the clutter when using it with other plugin. 

       

       

          [JENKINS-68135] Dot net SDK plugin shows too many option (.net build, etc.) in "add build steps" in the UI in free style job

          Not only would that lead to very cluttered an complicated interface for freestyle, it would be a mess to use in pipelines.

          What I could investigate is:

          • whether it's possible to prevent a step from being registered for freestyle use through a configuration option; that would then enable you to opt out of the convenience commands and just use the tool installation and wrapper functionality (leaving the invocation of actual dotnet commands to bat/pwsh/... steps
          • whether I can split the plugin into two; one with the core functionality, and a separate one with the convenience commands
          • what the effort would be to stop using the base class that gets me both freestyle and pipeline support with one codebase, and code the freestyle side separate

          Those last two options do seem to involve a lot of work for relatively little benefit.

          Tim Van Holder added a comment - Not only would that lead to very cluttered an complicated interface for freestyle, it would be a mess to use in pipelines. What I could investigate is: whether it's possible to prevent a step from being registered for freestyle use through a configuration option; that would then enable you to opt out of the convenience commands and just use the tool installation and wrapper functionality (leaving the invocation of actual dotnet commands to bat / pwsh /... steps whether I can split the plugin into two; one with the core functionality, and a separate one with the convenience commands what the effort would be to stop using the base class that gets me both freestyle and pipeline support with one codebase, and code the freestyle side separate Those last two options do seem to involve a lot of work for relatively little benefit.

          Sameer added a comment - - edited

          The first option seems to be good improvement to me. Thanks

          Sameer added a comment - - edited The first option seems to be good improvement to me. Thanks

          prevent a step from being registered for freestyle use through a configuration option

          config-builders.jelly calls Functions.getBuilderDescriptors, which calls BuildStepDescriptor.filter, which calls BuildStepDescriptor.isApplicable(Class<? extends AbstractProject>). So if you change CommandDescriptor.isApplicable to return false when the configuration option is set and the class is FreeStyleProject, I think that will exclude the steps from the freestyle project configuration UI. I'm not sure how changing the configuration option would affect freestyle projects that are already using these steps.

          Kalle Niemitalo added a comment - prevent a step from being registered for freestyle use through a configuration option config-builders.jelly calls Functions.getBuilderDescriptors , which calls BuildStepDescriptor.filter , which calls BuildStepDescriptor.isApplicable(Class<? extends AbstractProject>). So if you change CommandDescriptor.isApplicable to return false when the configuration option is set and the class is FreeStyleProject , I think that will exclude the steps from the freestyle project configuration UI. I'm not sure how changing the configuration option would affect freestyle projects that are already using these steps.

          Thanks - I used that approach, but with checkboxes configured per command. This allows keeping the "major" ones (say, restore/build/test/nuget push) but leaving out the more rarely used ones.
          Looks like there is no impact on what steps are currently in use by freestyle projects. The steps remain, you just can't add a new one.
          If the configuration code allows me to look through projects, I might add a warning when unchecking a command that is in use, but perhaps that isn't very relevant.

          Tim Van Holder added a comment - Thanks - I used that approach, but with checkboxes configured per command. This allows keeping the "major" ones (say, restore/build/test/nuget push) but leaving out the more rarely used ones. Looks like there is no impact on what steps are currently in use by freestyle projects. The steps remain, you just can't add a new one. If the configuration code allows me to look through projects, I might add a warning when unchecking a command that is in use, but perhaps that isn't very relevant.

          Configuration added. I'm looking into redesigning the steps, so that there's only one builder, with ".NET command" as property.
          On the freestyle side, that would mean a single "Execute .NET Command" builder to add, which would then have its own dropdown to select which of the available commands to run (which then has its config just like you have now).
          On the pipeline side, this would mean something like dotnetRestore(force: true, showSdkInfo: true) becomes dotnet(command: restore(force: true), showSdkInfo: true).

          Tim Van Holder added a comment - Configuration added. I'm looking into redesigning the steps, so that there's only one builder, with ".NET command" as property. On the freestyle side, that would mean a single "Execute .NET Command" builder to add, which would then have its own dropdown to select which of the available commands to run (which then has its config just like you have now). On the pipeline side, this would mean something like dotnetRestore(force: true, showSdkInfo: true) becomes dotnet(command: restore(force: true), showSdkInfo: true) .

          Sameer added a comment -

          Sameer added a comment -

          Sameer added a comment -

          Getting the above error for other user (non admin) after update to latest plugin version

           

          Sameer added a comment - Getting the above error for other user (non admin) after update to latest plugin version  

          Tim Van Holder added a comment - - edited

          Please make a new issue for that. And make sure to include how the user access rights have been configured (role strategy? what rights do they have on the job? etc.)

          Tim Van Holder added a comment - - edited Please make a new issue for that. And make sure to include how the user access rights have been configured (role strategy? what rights do they have on the job? etc.)

            zastai Tim Van Holder
            sameer1046 Sameer
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: