How to use "secret text" credential inside NodeJS app as part of a pipeline?

[Idan Adar]

I have done the following:

1. Create a "secret text" type credential

2. Put in the credential a password

3. Create a Global Variable, mySecret, with its value being the credential ID

4. In the declarative pipeline: 

stage ("E2E tests") {  
         environment {
            mySecret = credentials('${mySecret}')
         }
             
         steps {
            script {
               STAGE_NAME = "E2E tests"
               echo "++++++++++++ $mySecret"


               if (JOB_NAME == "e2e-dev") {
                  // Setup packages and run tests
                  sh '''
                     rm -f config/e2e-config.json
                     mv config/e2e-dev-config.json config/e2e-config.json
                     npm install
                     npm test
                  '''
               }
           }
        }
}

In Jenkins, the secret text is printed: "*****"

In the NodeJS app, I'm getting an error...

Global Variables in Jenkins can also be used as environment variables and I know I can use those as clear text in the NodeJS app.

My question is how to use Jenkins credentials from Jenkins in the NodeJS app...

Any thoughts?

[Joshua Noble]

The secret text being printed as *** is a feature, so credentials aren't leaked in console logs. You cannot use Jenkins credentials during application runtime. (ie: If you deploy a backend Node app to an app server) You can however use Jenkins credentials to run npm scripts, such as npm test, (which require the Node runtime) within a Jenkins build.

The credentials function needs an input of the credential ID. When a credential is created, you can set the ID value to a custom one, such as a human-friendly name. Otherwise, you will end up with a unique UUID.

Everyone has their own personal taste, but I would refactor the Jenkinsfile above to the following:

stage ("E2E tests") {  

  when {

    branch 'e2e-dev'

  }

  environment {

    MY_SECRET = credentials('jenkins-secret-id')

  }   

  steps {

    sh 'rm -f config/e2e-config.json'

    sh 'mv config/e2e-dev-config.json config/e2e-config.json'

    sh 'npm install'

    sh 'npm test'

  }

}

With the above Jenkinsfile, you should be able to reference your secret with ${MY_SECRET} anywhere in the code or shell steps, but only when running npm scripts. This will not work for running applications on a server. It should be noted that if you need to specify the secret within a shell step line, that line must use double quotes to resolve the variable properly.

Another way of doing this would be:

withCredentials([string(credentialsId: 'credential-id-here', variable: 'CUSTOM_VARIABLE_NAME_HERE')]) {

  sh "MY_SECRET=CUSTOM_VARIABLE_NAME_HERE npm test"

}

I hope that helps.

[Idan Adar]

Actually I think it does work... for the most part...

Working example:I created a "secret text" credential containing some password value and I then put the credential's ID as the value for a Global Variable called "myPassword".

In the Global Variables section there is a checkbox, "environment variables".

These key-value pairs apply for every build on every node. They can be used in Jenkins' configuration (as $key or ${key}) and will be added to the environment for processes launched from the build.

Then, in the Jenkinsfile I do as in my previous post.

environment {
    myPassword = credentials('${myPassword}')  
    ...
}

This extracts the value of the credential (the name references the ID) into myPassword.

Lastly, in the JavaScript I reference it as process.env.myPassword

When npm test is run as part of the Jenkinsfile, it works this way for all credentials that I "inject", except for a credential that is a JSON like this:

{"property":"value", "property": "value", "property": "value", "property": "value"}

This breaks for some reason.

When running locally (outside of jenkins) with npm test, the values are stored in a local .js file and it works flawlessly.

[Idan Adar]

Also, if I will print all of process.env when running npm test via the Jenkinsfile, I can see the Jenkins logs that the not-working value is printed...

[Idan Adar]

Working now. The problem was with another property that was defined as username/password credential and not secret text credential.