Notes
We want to provide the developer a more meaningful description of the steps in Blue Ocean.

For example, if we have a shell script being executed we'd like to provide the command as the description of that step. If we don't have that information, we'd like to fall back to a description of the step otherwise fall back to the step name.

One of the implementation challenges here is that we need to mask sensitive variables in the step description (example: an access token used in a shell command invoking AWS CLI, bound into the shell command by environment variable). This information CANNOT be stored or displayed in a step

We also need to limit the size of data that is stored in recorded Step in case (for example writeFile) large data is being passed via variables

Where potentially hidden content is present, initially none of the String's content will be stored or displayable. Later we may try to replace the variable content with the EnvVars name, i.e. "my password is $passwordVar" which would execute as 'my password is s3cretC0ntent' becomes 'my password is ${passwordVar}' (so we know a variable was used). This is desirable and helpful for users but adds a slight risk of accidentally leaking a secret if present in normal String content somewhere.

Implementation:

We will use the EnvVars (the only thing we have to work with here) to detect sensitive strings included in String parameters, by looking for the value of EnvVars in that content.

To reduce false positives, the safe/standard global environment variables for a pipeline will be removed from this list of EnvVars

Lots of discussion about how to separate sensitive and nonsensitive environment variable content (markers for data, whitelist/blacklist, or custom information in their EnvVars definitions) – Jesse Glick has suggested a clever approach:

to play with a different way of detecting secrets you would patch `BindingStep` and `MaskPasswordsBuildWrapper` to, say, not just set `PASSWORD=s3cr3t` but also `PASSWORD+SECRET=true`, and then document this somewhere like in `EnvironmentExpander`

Sam Van Oort
added a comment - 2017-01-11 23:37 - edited To capture discussion from today with Jesse Glick and James Dumay and others:
Requirements added:
One of the implementation challenges here is that we need to mask sensitive variables in the step description (example: an access token used in a shell command invoking AWS CLI, bound into the shell command by environment variable). This information CANNOT be stored or displayed in a step
We also need to limit the size of data that is stored in recorded Step in case (for example writeFile) large data is being passed via variables
Where potentially hidden content is present, initially none of the String's content will be stored or displayable. Later we may try to replace the variable content with the EnvVars name, i.e. "my password is $passwordVar" which would execute as 'my password is s3cretC0ntent' becomes 'my password is ${passwordVar}' (so we know a variable was used). This is desirable and helpful for users but adds a slight risk of accidentally leaking a secret if present in normal String content somewhere.
Implementation:
We will use the EnvVars (the only thing we have to work with here) to detect sensitive strings included in String parameters, by looking for the value of EnvVars in that content.
To reduce false positives, the safe/standard global environment variables for a pipeline will be removed from this list of EnvVars
We may also attempt to remove local computer environment variables as with https://github.com/jenkinsci/docker-workflow-plugin/blob/916bdb728fdff51709933e653ce6baa867b7bebb/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L125-L127
Comment:
Lots of discussion about how to separate sensitive and nonsensitive environment variable content (markers for data, whitelist/blacklist, or custom information in their EnvVars definitions) – Jesse Glick has suggested a clever approach:
to play with a different way of detecting secrets you would patch `BindingStep` and `MaskPasswordsBuildWrapper` to, say, not just set `PASSWORD=s3cr3t` but also `PASSWORD+SECRET=true`, and then document this somewhere like in `EnvironmentExpander`

Sam Van Oort - one thing the requirement doesn't capture, that is also request by JENKINS-41156, is the simple ability to rename a step. While the dynamic nature of pulling stuff out of the command for display might be useful, a lot could be solved by providing a better solution than this workaround.

Ryan Hutchison
added a comment - 2017-02-14 20:32 - edited Sam Van Oort - one thing the requirement doesn't capture, that is also request by JENKINS-41156 , is the simple ability to rename a step. While the dynamic nature of pulling stuff out of the command for display might be useful, a lot could be solved by providing a better solution than this workaround.
try {
bat " do stuff"
}
finally {
CpsThread.current().head.get().addAction( new LabelAction( "name of step" ))
}
Unfortunately `stage` does not work.
cc: Jesse Glick James Dumay

@jglick has noted in the nested stages issue (and previous discussions we've had on N-related tickets) nested stages aren't something we can recommend to people to solve the labeling of steps. The interpretation of what this means to users is loose and none of our visualizations support it.

James Dumay
added a comment - 2017-02-15 19:42 @jglick has noted in the nested stages issue (and previous discussions we've had on N-related tickets) nested stages aren't something we can recommend to people to solve the labeling of steps. The interpretation of what this means to users is loose and none of our visualizations support it.

Patrick Wolf
added a comment - 2017-02-15 22:04 I agree with James Dumay . It is ridiculous to expect users to wrap every step in a pipeline in a new stage. This is especially true in Declarative Pipeline where stage has a much more defined meaning.

We already have a task in progress to display a sh command (for example). If you need some additional human-readable display for one or a sequence of steps beyond that, stage already works (just not in Blue Ocean) and is as easy as anything else.

Jesse Glick
added a comment - 2017-02-16 17:48 We already have a task in progress to display a sh command (for example). If you need some additional human-readable display for one or a sequence of steps beyond that, stage already works (just not in Blue Ocean) and is as easy as anything else.

Ryan Campbell
added a comment - 2017-02-22 23:52 For Blue Ocean team to review this:
We need examples of what the output would be
What steps are supported vs. what aren't
How are new steps supported?
-> Do plugin authors provide this or must Blue Ocean provide every implementation?
--> OK if not for first delivery, but need this for the definition of done.

Sample outputs: this is a requirement, so I'll let Blue Ocean define this. I think for single-argument steps such as shell, batch, and node, probably just the input argument. For multi-argument steps, some sort of formatted string (format not agreed on at this point). One example, perhaps for git plugin: 'url: ${gitUrl}, branch: ${branch}, credentialsId: ${id}, changeLog: [true/false], poll: [true/false]'

Steps supported: all steps will get their parameters saved, single-argument steps will get the format serialized via toString probably, multi-argument steps it's

New steps supported:

Blue Ocean agreed to submit PRs for initial implementation of the parameters-to-string method, others can be provided by plugin authors (optional API)

I would think 80% of it is "Shell Script" - which ideally would be the script being called - or some part of it right?

For things like archive, should parameters is highly useful, as are things like invoking jobs.
The rest are a very very long very very thin tail of things - but things like the above would satisfy many people for a long time.

Basically if the common ones are taken care of, the long tail can take its time.

Michael Neale
added a comment - 2017-03-01 07:28 I would think 80% of it is "Shell Script" - which ideally would be the script being called - or some part of it right?
For things like archive, should parameters is highly useful, as are things like invoking jobs.
The rest are a very very long very very thin tail of things - but things like the above would satisfy many people for a long time.
Basically if the common ones are taken care of, the long tail can take its time.

Stage is not a reasonable solution. We currently have 50+ shell scipts that we would eventually like to label. Using Stage creates a very user-unfriendly stage view. As mentioned above this issue is not tied directly to Blue Ocean, and I dont think it can be solved by stage view. For the short term, I think adding a label to 'sh' command, that is displayed in the pipeline view instead of "shell command" would be very helpful. I know this has been mentioned before and closed as Not A Bug.

Andrea Knight
added a comment - 2017-05-11 01:08 Stage is not a reasonable solution. We currently have 50+ shell scipts that we would eventually like to label. Using Stage creates a very user-unfriendly stage view. As mentioned above this issue is not tied directly to Blue Ocean, and I dont think it can be solved by stage view. For the short term, I think adding a label to 'sh' command, that is displayed in the pipeline view instead of "shell command" would be very helpful. I know this has been mentioned before and closed as Not A Bug.

James Dumay
added a comment - 2017-05-11 01:11 Andrea Knight this ticket is almost done and you should get something that looks like the screenshot below - does that fit your use case? You would not have to use stage to provide the label.

mohamed badran
added a comment - 2017-05-11 09:46 James Dumay
This looks interesting but how you'll specify that "comment part". Will this be automatic? Or there will be new syntax i can put to name any step i do?

Andrea Knight
added a comment - 2017-05-11 13:42 James Dumay yes, that does look good, and would work for our needs in the Blue Ocean view, especially since it does not require stages. Would the same labels also display in the Pipeline Steps view?

Michael Neale
added a comment - 2017-05-18 23:15 Just moving this blue ocean one to the top of the board so when the depenencies are available, the next free person can finish off the UI aspects (nearly there!)

Sam Van Oort
added a comment - 2017-05-24 14:11 Stage View will have UI support for this once I cut the next release (the feature is merged in, I'm just waiting to cut a release until I can finish reviewing/testing the existing PRs).

James Dumay
added a comment - 2017-06-05 00:52 Cliff Meyers actually could you please pick this one ASAP? Theres some issues around wrapping rules here now that we've merged the work in
! #2 2017-06-05 10-50-45.png|thumbnail!

Michael Neale
added a comment - 2017-07-07 00:05 Hi Jakub Pawlinski - best to ask that on a jenkins mailing list than a closed ticket. You can certainly make custom steps to do that but that is likely overkill. I am not sure if that is possible.

jake bishop
added a comment - 2017-07-07 09:27 Jakub Pawlinski - we are also looking to do this. If you ask on a mailing list could you add a link to it here so that future people that browse here can also find it?

Jesse Glick
added a comment - 2017-07-13 14:56 How can I make custom description on step, i.e. replace the "@echo Hello World — Windows Batch Script" blue ocean entry with "Hello World Step — Windows Batch Script"
You cannot. This is not supported.

Is is possible to have this information in the FlowGraphTable display of Rows? We have so many rows and steps they are not being successfully by the BlueOcean. We exceed the numbers of branches that will be displayed.

Andrea Knight
added a comment - 2017-07-28 18:15 Is is possible to have this information in the FlowGraphTable display of Rows? We have so many rows and steps they are not being successfully by the BlueOcean. We exceed the numbers of branches that will be displayed.

Michael Neale
added a comment - 2017-07-31 00:56 Andrea Knight I think you are seeing: https://issues.jenkins-ci.org/browse/JENKINS-42781 - there is a limit of 100 (not often hit, but if you can add your notes to that ticket ,I will bump priority).

Andrea Knight
added a comment - 2017-07-31 20:05 Jesse Glick that is exactly what I am looking for.
Unfortunately, I cannot incorporate the change into our production system until it is made available via a plugin. I am looking forward to it being available.
Thanks

I am using the latest version (2.20) of the Pipeline Supporting API plugin, and all dependencies are updated. I am not seeing the ArgumentsColumn feature. Is there something that needs to be enabled to allow it to work?

Andrea Knight
added a comment - 2017-09-17 03:03 I am using the latest version (2.20) of the Pipeline Supporting API plugin, and all dependencies are updated. I am not seeing the ArgumentsColumn feature. Is there something that needs to be enabled to allow it to work?

Gil Shinar
added a comment - 2017-12-03 08:51 - edited Can someone please help me understand which plugins should be installed (including versions) and what should I add to the pipeline to see the description?

James Dumay
added a comment - 2017-12-04 01:11 Please do not pile any more comments on top of this issue. If you have specific problems or feature requests, please open other tickets or ask on the Jenkins Users mailing list .

Sam Van Oort
added a comment - 2018-07-26 13:36 Leandro Lucarella It's fixed because steps now show the arguments used to run them (if they can be easily converted to strings or provide an implementation for it).

Sam Van Oort
added a comment - 2018-07-26 13:43 Konrad Pustenik Please do not go around arbitrarily changing ticket statuses on other peoples' tickets – undoing this costs time we could be spending on making Jenkins better.

Vicky Chijwani
added a comment - 2018-09-25 12:55 If anyone is looking for a way to provide a custom label to a shell step, I've created this plugin that adds a labelledShell step which accepts a label argument: https://github.com/jenkinsci/labelled-steps-plugin/

Thales Pereira - I was thinking maybe we could add label support for other common steps as well. That's why I named the plugin labelled-steps instead of labelled-shell-step

I don't know if it's going to be feasible / easy to support other steps, but it's worth a shot (sh step was thankfully trivial to modify). Hopefully at some point Jenkins core will support custom labels for any step.

Vicky Chijwani
added a comment - 2018-09-25 13:15 - edited Thales Pereira - I was thinking maybe we could add label support for other common steps as well. That's why I named the plugin labelled-steps instead of labelled-shell-step
I don't know if it's going to be feasible / easy to support other steps, but it's worth a shot (sh step was thankfully trivial to modify). Hopefully at some point Jenkins core will support custom labels for any step.

I still advocate maintaining a separation of duties, so that stage is used for adding a human-readable label to a step or sequence of steps. If Blue Ocean fails to display nested stages well, then improve Blue Ocean.

Jesse Glick
added a comment - 2018-09-25 14:48 This is Pipeline, not Jenkins core BTW.
I still advocate maintaining a separation of duties, so that stage is used for adding a human-readable label to a step or sequence of steps. If Blue Ocean fails to display nested stages well, then improve Blue Ocean.

Jesse Glick - you're right. I loosely said "Jenkins core" as a way to say "officially supported by CloudBees". If nested stages can support the use-case of labelling a group of steps (especially shell steps) without creating a new node in the pipeline visualization, that would also perfectly solve the issue.

Come to think of it, there's a very similar proposal at JENKINS-44094, about grouping a set of steps with a custom label. That would solve multiple problems.

Vicky Chijwani
added a comment - 2018-09-25 15:14 Jesse Glick - you're right. I loosely said "Jenkins core" as a way to say "officially supported by CloudBees". If nested stages can support the use-case of labelling a group of steps (especially shell steps) without creating a new node in the pipeline visualization, that would also perfectly solve the issue.
Come to think of it, there's a very similar proposal at JENKINS-44094 , about grouping a set of steps with a custom label. That would solve multiple problems.

Veaceslav Gaidarji
added a comment - 2018-09-25 22:30 Still not sure that wrapping each and every "sh" step into a stage block is a good idea for providing a description for sh step.
There should be a possibility to label sh step (and probably other steps) and it was mentioned here .
I had a plan to enhance "sh" step API and add "label" parameter (as discussed with Sam Van Oort ). Just need to find time for that.

Dana Goyette
added a comment - 2018-10-17 01:48 - edited As it is now, the sh script is quite unreliable about ever saying anything more than just "Shell Script".
Shouldn't single-line commands show the command being executed? For me, they almost never do.
These steps show the command:
sh(script: "/usr/bin/env python ./install_manager.py --jenkins --uninstall-all")
sh(script: "/usr/bin/env python ./install_manager.py --jenkins --fail-if-leftovers --uninstall-all")
These steps show just "Shell Script", rendering the summary useless:
sh(script: "/usr/bin/env python ./install_manager.py --jenkins --build-id 123456 --install")
sh(script: "/usr/bin/env python ./install_manager.py --jenkins --build-id 123456 --uninstall")
Adding or removing the /usr/bin/env didn't change anything, either.
Note that my actual script is actually calling sh with a Map as a parameter, rather than passing named parameters.
If I use the labelledShell step, even that description sometimes gets ignored.

Dana Goyette, I haven't tested this in a while, but I believe your issue there is using variables like the build id, assuming you used the actual number of the current build. In my experience, Jenkins goes to lengths to identify and mask data like that.

Phil McArdle
added a comment - 2018-10-17 10:08 Dana Goyette , I haven't tested this in a while, but I believe your issue there is using variables like the build id, assuming you used the actual number of the current build. In my experience, Jenkins goes to lengths to identify and mask data like that.

Thanks for the hint about the issue being variables. That seems to be it: if I use any variables (in the stock sh step's command or the labelledShell step's label), then the label is just silently ignored! Should I file a separate ticket for that brokenness?

Dana Goyette
added a comment - 2018-10-18 23:25 Thanks for the hint about the issue being variables. That seems to be it: if I use any variables (in the stock sh step's command or the labelledShell step's label), then the label is just silently ignored! Should I file a separate ticket for that brokenness?

boris avney
added a comment - 2019-03-03 13:20 Hi,
Where can I find which BO version has this functionality?
(couldn't find the PR in change log: https://wiki.jenkins.io/display/JENKINS/Blue+Ocean+Plugin)