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

labels and step script content shown inconsistently in blue ocean steps

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • blueocean-plugin
    • None
    • Jenkins ver. 2.190.1
      Blue Ocean - BlueOcean Aggregator - 1.19.0

      Somewhat related to JENKINS-53649 and as described there, but this feels like it deserves it's own ticket.

      The content of a step in the B/O step summary seems inconsistent:

      Those two steps in the red box are both of the form:

      sh label: <label_name>,
         script: '''...'''
      

      The first one is in the steps portion of the stage and looks like:

      sh label: env.STAGE_NAME,
         script: '''...'''
      

      and the second one is in the post->success portion of the stage and looks like:

       sh label: "Collect artifacts",
           script: '''...'''
      

      But as you can see, they are displayed quite differently.  But why?

      It doesn't seem like they should be.  The second step shouldn't have the label prefixed with the script content of step.

          [JENKINS-59918] labels and step script content shown inconsistently in blue ocean steps

          David Dumas added a comment -

          This issue is frustrating, I can't find a workaround to have a clean step name all the time in BlueOcean UI.

          David Dumas added a comment - This issue is frustrating, I can't find a workaround to have a clean step name all the time in BlueOcean UI.

          This has gotten worse in the recent year. Now every shell step in the workflow instance spews out script contents instead of the actual label specified, however the label is included at the tail end of the step.

          Dmitry Seryogin added a comment - This has gotten worse in the recent year. Now every shell step in the workflow instance spews out script contents instead of the actual label specified, however the label is included at the tail end of the step.

          Weirdly enough this bug seems to be dependent on the length of the script that is executed? At least that workaround worked for us. We just added some (annoying but useful) comments into our shell scripts. Each script is displayed by the label now, instead of leaking secrets due to the command.

          Michael Kemmerzell added a comment - Weirdly enough this bug seems to be dependent on the length of the script that is executed? At least that workaround worked for us. We just added some (annoying but useful) comments into our shell scripts. Each script is displayed by the label now, instead of leaking secrets due to the command.

          Hari added a comment - - edited

          +1 someone please fix this - it's been bugging me for years at this point spewing shell step contents all over Blue Ocean.

          I can find no consistency between when Blue Ocean chooses to respect the step label vs printing the shell script contents.

          Look how similar these 2 functions are and yet even they're treated differently and I can't explain why:

          https://github.com/HariSekhon/Jenkins/blob/master/vars/garDockerAuth.groovy

          https://github.com/HariSekhon/Jenkins/blob/master/vars/gcrDockerAuth.groovy

          The 3rd and 5 steps shown in the screenshot below are the final sh() step in garDockerAuth.groovy and gcrDockerAuth.groovy respectively which are almost identical and the same length - yet one prints the label, and the other prints the shell script contents which is ugly and leaks too much information.

          garDockerAuth's final sh() step which uses the label nicely:

            sh (
              label: 'GCloud SDK Configure Docker Authentication for Google Artifact Registry',
              script: """
                set -eux
                if [ -n "\${GAR_PROJECT:-}" ]; then
                  export CLOUDSDK_CORE_PROJECT="\$GCR_PROJECT"
                fi
                # XXX: fails without throwing non-zero exit code for invalid registries with
                #      WARNING: blah is not a supported registry
                gcloud auth configure-docker --quiet '$registries'
              """
            ) 

          vs gcrDockerAuth()'s final sh() step which spews shell code all over the screen:

            sh (
              label: 'GCloud SDK Configure Docker Authentication for Google Container Registry',
              script: """
                set -eux
                if [ -n "\${GCR_PROJECT:-}" ]; then
                  export CLOUDSDK_CORE_PROJECT="\$GCR_PROJECT"
                fi
                # XXX: fails without throwing non-zero exit code for invalid registries with
                #      WARNING: blah is not a supported registry
                gcloud auth configure-docker --quiet '$registries'
              """
            ) 

          The diff is literally this - so it's not even a matter of sh() step content length mkemmerz  (I did have this hunch previously but this seems to disprove it):

          diff /tmp/tmp /tmp/tmp2
          2c2
          <     label: 'GCloud SDK Configure Docker Authentication for Google Artifact Registry',
          ---
          >     label: 'GCloud SDK Configure Docker Authentication for Google Container Registry',
          5c5
          <       if [ -n "\${GAR_PROJECT:-}" ]; then
          ---
          >       if [ -n "\${GCR_PROJECT:-}" ]; then 

          So basically... wtf blue ocean...

           

          Hari added a comment - - edited +1 someone please fix this - it's been bugging me for years at this point spewing shell step contents all over Blue Ocean. I can find no consistency between when Blue Ocean chooses to respect the step label vs printing the shell script contents. Look how similar these 2 functions are and yet even they're treated differently and I can't explain why: https://github.com/HariSekhon/Jenkins/blob/master/vars/garDockerAuth.groovy https://github.com/HariSekhon/Jenkins/blob/master/vars/gcrDockerAuth.groovy The 3rd and 5 steps shown in the screenshot below are the final sh() step in garDockerAuth.groovy and gcrDockerAuth.groovy respectively which are almost identical and the same length - yet one prints the label, and the other prints the shell script contents which is ugly and leaks too much information. garDockerAuth's final sh() step which uses the label nicely:   sh (     label: 'GCloud SDK Configure Docker Authentication for Google Artifact Registry' ,     script: """       set -eux       if [ -n "\${GAR_PROJECT:-}" ]; then         export CLOUDSDK_CORE_PROJECT= "\$GCR_PROJECT"       fi       # XXX: fails without throwing non-zero exit code for invalid registries with       #      WARNING: blah is not a supported registry       gcloud auth configure-docker --quiet '$registries'     """   ) vs gcrDockerAuth()'s final sh() step which spews shell code all over the screen:   sh (     label: 'GCloud SDK Configure Docker Authentication for Google Container Registry' ,     script: """       set -eux       if [ -n "\${GCR_PROJECT:-}" ]; then         export CLOUDSDK_CORE_PROJECT= "\$GCR_PROJECT"       fi       # XXX: fails without throwing non-zero exit code for invalid registries with       #      WARNING: blah is not a supported registry       gcloud auth configure-docker --quiet '$registries'     """   ) The diff is literally this - so it's not even a matter of sh() step content length mkemmerz   (I did have this hunch previously but this seems to disprove it): diff /tmp/tmp /tmp/tmp2 2c2 <     label: 'GCloud SDK Configure Docker Authentication for Google Artifact Registry' , --- >     label: 'GCloud SDK Configure Docker Authentication for Google Container Registry' , 5c5 <       if [ -n "\${GAR_PROJECT:-}" ]; then --- >       if [ -n "\${GCR_PROJECT:-}" ]; then So basically... wtf blue ocean...  

            Unassigned Unassigned
            brianjmurrell Brian J Murrell
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: