more meaningful description of a step

241 views
Skip to first unread message

Jakub Pawlinski

unread,
Jul 11, 2017, 3:51:55 AM7/11/17
to Jenkins Users
Hi, 


In sprint review Sam Van Oort demonstrated the foundation for this https://www.youtube.com/watch?v=HhiUY70RVJY&t=510 

He mentions there possibility of having custom caption but I have found no way to actually achieve it.

Maybe you know how I could make a custom description of step in declarative pipeline, far too simple example:

stages {
  stage('A') { 
    steps {
      bat "@echo Hello World"

        }
    }
}


How can I make it appear as "Hello World Step — Windows Batch Script" instead of "@echo Hello World — Windows Batch Script" that I'm getting now.


Thanks

Jakub


Samuel Van Oort

unread,
Jul 11, 2017, 12:31:37 PM7/11/17
to Jenkins Users
Hi Jakub, 
Custom captions (or more accurately, custom step argument descriptions) are supported on a per-Step type basis, so if your plugin is defining a new Step type, you can define how to display its inputs. There isn't anything coming immediately to allow you to customize captions individually -- though there is a future enhancement to allow attaching metadata to a step that might be displayed in some fashion.  But I assume that would be in addition to the caption, not in place of it.  Apologies for any confusion from the demos.

Cheers, 
Sam

Torsten Gippert

unread,
Jul 12, 2017, 4:34:48 AM7/12/17
to Jenkins Users

Hello,

I am a bit confused how to handle sensitive information when using a shell script:

In https://issues.jenkins-ci.org/browse/JENKINS-37324 Sam Van Oort wrote ( "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`"


The question is, how do I hide sensitive information that DO NOT come from credential binding in the shell script header? 

Example:

String userAndPwd = "test:123" // this comes from an manual input step
def userAndPwdSECRET = true // Doesn't do anything ?! (`PASSWORD+SECRET=true)

sh """
   set +x
   curl -u ${userAndPwd} https://www.google.com
"""  

In Blue Ocean I see "set +x curl -u test:123 https://www.google.com - Shell Script"

How can I mask out test:123 (=${userAndPwd})  in the shell script description header in Blue Ocean?

Many thanks to any answer in advance :-)

Samuel Van Oort

unread,
Jul 17, 2017, 2:15:59 PM7/17/17
to Jenkins Users
Torsten, 

> how do I hide sensitive information that DO NOT come from credential binding in the shell script header?

First, I would strongly discourage this approach in general.  Credentials and credentials-binding exist specifically to provide a secure mechanism for build secrets (with several levels of security around them), and if you break from that it's very easy to shoot yourself in the foot and leak something sensitive.

A better approach would be to select from a list of credential ids.  

Second, as a workaround, if you have one of the cases where you can't do that, if you bind the secret to an actual environment variable (rather than a pipeline variable) it will currently be masked automatically by the implementation.  However I cannot guarantee the implementation will not become more specific about what it masks in the future (as described in the ticket above), ergo why I strongly encourage appropriate use of credentials.

Note that for purposes of step description, masking means that *all* of the string is removed, rather than just masking out part with asterisks.  This is to make one class of dictionary password attack harder to conduct, by not revealing what part of the input is sensitive.

Regards,
Sam Van Oort

Jesse Glick

unread,
Jul 17, 2017, 4:11:36 PM7/17/17
to Jenkins Users
On Monday, July 17, 2017 at 2:15:59 PM UTC-4, Samuel Van Oort wrote:
A better approach would be to select from a list of credential ids.  

Specifically you can either keep credentials associated with the build; or request user-scoped credentials as a build parameter.

Failing that, you could also use the Mask Passwords wrapper step to mask uses of a string within a block.
Reply all
Reply to author
Forward
0 new messages