Possibly “for free” from JENKINS-31582.

We clone multiple SCM repositories. They are identified by the ScmName parameter, but we can not see the difference in BO. This is very annoying.

checkout([$class: 'GitSCM',
                branches: [[name: branch]],
                doGenerateSubmoduleConfigurations: false,
                extensions: [[$class: 'CleanCheckout'], [$class: 'ScmName', name: 'super']],
                submoduleCfg: [],
                userRemoteConfigs: [[url: "${gitBaseUrl}/${superRepo}"]]])

Here is the repo called 'super'

same goes for almost any step – read file from repo – which file?

sh – which script? which name?

cc Sam Van Oort this is the ticket I was talking about - some good ideas thrown around

If you want more background and why we clone so much repos – https://roidelapluie.be/blog/2016/11/18/gitslave-jenkins/

Julien Pivotto right, fair point. Are there other steps you use often that need a more useful description based on what they actually did?

in progress NICE!

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`

Thanks Sam Van Oort

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.

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.

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.

To answer from my understanding Ryan Campbell:

• 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.

This isn't restricted to just Blue Ocean, the same inadequate information in executing shell/bat/other steps exists in the 'standard' Pipeline Stage. 

I'm on rc3 and don't see any change.

Do I need to specify the name for each step or something? How it should work and parse the command I execute?

This ticket is still In Progress.

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 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.

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?

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?

Andrea Knight Sure would. I've got a beta out that offers a basic implementation of this, just fine-tuning some of the implementation details.

Sam Van Oort Sounds great. We are looking forward to it! Thanks!

Sam Van Oort demonstrated the foundation for this work this morning:  

https://www.youtube.com/watch?v=HhiUY70RVJY&t=510

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!)

Code changed in jenkins
User: Sam Van Oort
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/actions/ArgumentsAction.java
src/main/java/org/jenkinsci/plugins/workflow/graphanalysis/AbstractFlowScanner.java
src/test/java/org/jenkinsci/plugins/workflow/graphanalysis/FlowTestUtils.java
http://jenkins-ci.org/commit/workflow-api-plugin/6ee30a545ea341bf6d2710aaaea58397c63f740b
Log:
Merge pull request #26 from jenkinsci/step-action-jenkins-37324

JENKINS-37324 Step action API

Compare: https://github.com/jenkinsci/workflow-api-plugin/compare/03c18c83d083...6ee30a545ea3

Code changed in jenkins
User: Sam Van Oort
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java
src/main/java/org/jenkinsci/plugins/workflow/cps/actions/ArgumentsActionImpl.java
src/main/java/org/jenkinsci/plugins/workflow/cps/steps/ParallelStep.java
src/test/java/org/jenkinsci/plugins/workflow/cps/DSLTest.java
src/test/java/org/jenkinsci/plugins/workflow/cps/DescriptorMatchPredicate.java
src/test/java/org/jenkinsci/plugins/workflow/cps/actions/ArgumentsActionImplTest.java
src/test/java/org/jenkinsci/plugins/workflow/testMetaStep/MonomorphicStep.java
http://jenkins-ci.org/commit/workflow-cps-plugin/4d402bb2bf5828b141ed01c70c8dfcde59a9e9d1
Log:
Merge pull request #98 from jenkinsci/store-step-for-flownode-jenkins-37324

JENKINS-37324 Store parameter info for steps as an action on the flownode

Compare: https://github.com/jenkinsci/workflow-cps-plugin/compare/c6dfd2525f64...4d402bb2bf58

The backend parts are now fully live (all are in the update center). 

This is great stuff mate

Code changed in jenkins
User: Sam Van Oort
Path:
rest-api/pom.xml
rest-api/src/main/java/com/cloudbees/workflow/rest/external/FlowNodeExt.java
rest-api/src/test/java/com/cloudbees/workflow/rest/endpoints/JobAndRunAPITest.java
ui/pom.xml
ui/src/main/js/view/templates/stage-logs.hbs
http://jenkins-ci.org/commit/pipeline-stage-view-plugin/29b14fc6c51c2af58eb9c776a3fc3104ca171f4f
Log:
Merge pull request #39 from jenkinsci/step-descriptions-poc

JENKINS-37324 Step descriptions proof of concept

Compare: https://github.com/jenkinsci/pipeline-stage-view-plugin/compare/2fbf4c02fea4...29b14fc6c51c

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). 

Cliff Meyers could you please take care of the frontend changes for this please? The implementation has been merged with master.

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!

Merged to master and 1.1.0 branches.

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" for:
stages {
  stage('A') { 
    steps {
      bat "@echo Hello World"

        }
    }
}

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. 

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?

added my question to https://groups.google.com/forum/#!topic/jenkinsci-users/RzRvg8uELuA

thanks for pointing this mailing lists out

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 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 try https://github.com/jenkinsci/workflow-support-plugin/pull/39 for that.

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

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/support/visualization/table/ArgumentsColumn.java
src/main/resources/org/jenkinsci/plugins/workflow/support/visualization/table/ArgumentsColumn/column.jelly
http://jenkins-ci.org/commit/workflow-support-plugin/862dbaedf528daeeb9a662417001bff1ac61ad3b
Log:
JENKINS-37324 Add an ArgumentsColumn to the FlowGraphTable display.

Code changed in jenkins
User: Andrew Bayer
Path:
pom.xml
src/main/java/org/jenkinsci/plugins/workflow/support/visualization/table/ArgumentsColumn.java
src/main/resources/org/jenkinsci/plugins/workflow/support/visualization/table/ArgumentsColumn/column.jelly
http://jenkins-ci.org/commit/workflow-support-plugin/6515ef81f3a67cdfb0822206299d5a6f4cb2e7fc
Log:
Merge pull request #39 from jglick/ArgumentsColumn-JENKINS-37324

JENKINS-37324 Add an ArgumentsColumn to the FlowGraphTable display

Compare: https://github.com/jenkinsci/workflow-support-plugin/compare/1074bea008ef...6515ef81f3a6

Jesse Glick when do you expect a release of the workflow-support-plugin that contains the new arguments column?

Andrea Knight I am not cutting releases. Up to Andrew Bayer / Sam Van Oort. Or you can install a snapshot.

Andrea Knight Tomorrow probably – we're holding off excess plugin releases today to avoid interference with additional release activity

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?

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?

Gil Shinar I couldn't tell you exactly, but it should be the latest of everything required to run Blue Ocean and Blue Ocean itself.

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.

How is this fixed? Via the new nested stages or a way to attach some label to any step will be actually added?

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).

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.

Hi Cliff Meyers, this was implemented ? Or there's any alternative for this suggestion available for usage?

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/

Vicky Chijwani You are a life saver, thank you. Let me know if you need help for maintaining it.

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.

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.

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.

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.

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?

If you wanted something like that changed, that'd be a separate issue, yep

I think that's running at a much lower level than the step labelling.

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

See JENKINS-47101.

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)