Struggling to Understand Environment Variables

Using Jenkins Ask a question
1

I’m trying to write a pipeline that pulls code from a Bitbucket repo, build it, package it into an RPM, and then pushes the RPM to a Nexus repo. It all works if I hardcode the filename into the Nexus step, but when I try to use a variable I keep getting errors. I’ve looked through the docs and found the environmental variables built into Jenkins and also Bitbucket, but when I try to test them with an echo or sh I run into errors or it tells me there’s no variable with that name. Here’s the beginning of my pipeline up to the test:

pipeline {

    agent {
        label 'nodejs'
    }

    parameters {
        choice choices: ['dev', 'alpha', 'reseller', 'integrate', 'productioncp', 'productionc1', 'productionc2'], description: 'Describe the environment we want to build for.', name: 'ENVIRONMENT'
        booleanParam name: 'RUN_VERACODE', defaultValue: false, description: 'Run Veracode Scan' 
    }

    triggers {
        bitbucketPush buildOnCreatedBranch: true, overrideUrl: '<repo URL>'
    }

    options {
        buildDiscarder logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '12', daysToKeepStr: '', numToKeepStr: '12')
    }

    stages {
        stage ('Checking out from BitBucket') {
            steps {
                bbs_checkout( 
                branches: [
                    [name: '*/develop']
                    ],
                credentialsId: '<redacted>',
                id: '<redacted>',
                projectName: '<project>',
                repositoryName: '<repo name>',
                serverId: '<redacted>',
                sshCredentialsId: 'bitbucket-ssh'
                )
            }
        }

        stage ('test') {
            steps {
                script {
                  echo 'Running tests'
                  echo ${BRANCH_NAME} ${TAG_NAME} ${JOB_NAME} ${GIT_BRANCH} ${BITBUCKET_REPO_SLUG}
                }
            }
        }

I’ve also tried the following:

echo "${BRANCH_NAME}"
echo ${BRANCH_NAME}
echo BRANCH_NAME
echo env.BRANCH_NAME
sh "echo BRANCH_NAME ${BRANCH_NAME}"

I either get an error along the lines of:

git rev-list --no-walk 7a7a238ce08201d420b1b2511bd5af387a235ad9 # timeout=10
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 50: expecting '}', found 'Running tests' @ line 50, column 26.
                     - echo 'Running tests'
                            ^

or

> git rev-list --no-walk 61282f8f91c53cc5e759670c6d914d55d62812fd # timeout=10
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 44: Expected a symbol @ line 44, column 17.
                   echo BRANCH_NAME TAG_NAME JOB_NAME
                   ^

and finally

[Pipeline] End of Pipeline
groovy.lang.MissingPropertyException: No such property: BRANCH_NAME for class: groovy.lang.Binding
	at groovy.lang.Binding.getVariable(Binding.java:63)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:266)
2

You need to quote this.

In this case you need double . Double quotes get interpreted by groovy/Jenkins file.
Single quotes gets passed through directly. Great for sh statements were you waNNbt shell to handle the variables

3

When I use double quotes I get:

groovy.lang.MissingPropertyException: No such property: BRANCH_NAME for class: groovy.lang.Binding
4

I think branch name is only auto set for multibranch pipelines. Maybe single pipelines that use SCM for the pipeline. If you fill in the text area manually it won’t be set.

I don’t know anything about the Bitbucket implementation specifically but the checkout step returns a bunch of variables.

I’m going to ping @MarkEWaite who might know more. I need to go back to bed.

5

Well my biggest issue is how to I stop hard coding:

My_Package_Name-4.9.18-00195.el7.x86_64.rpm

and instead can use:

${JOB_NAME}-${RELEASE}.x86_64.rpm
6

“${JOB_NAME}-${RELEASE}.x86_64.rpm” is how you would need to use it. I don’t see where this would be used in your pipeline above, can you share your entire pipeline (redacted)?

7

Thanks for the response. I kinda inherited this when I joined my team so I went ahead and stripped down the pipeline to the bare minimum and it’s looking something like the following. I “redacted” fields since this is for my company:

pipeline {
    agent {
        label 'nodejs' 
    }

    triggers {
        bitbucketPush buildOnCreatedBranch: true, overrideUrl: 'https://<repo url>'
    }

    options {
        buildDiscarder logRotator(artifactDaysToKeepStr: '', artifactNumToKeepStr: '12', daysToKeepStr: '', numToKeepStr: '12')
    }

    stages {
        stage ('Checking out from BitBucket') {
            steps {
                bbs_checkout( 
                branches: [
                    [name: '*/develop']
                    ],
                credentialsId: '8678e029-b51f-4e56-8f78-47642ef1e856',
                id: '70753d0e-e717-4085-9789-fc41cad97ecf',
                projectName: '<Project>',
                repositoryName: '<repo name>',
                serverId: 'd4051227-3587-4fb7-bb32-a05bdc3531ec',
                sshCredentialsId: 'bitbucket-ssh'
                )
            }
        }

        stage ('Build') {
            steps {
                echo 'Building Artifacts'
                sh 'make rpm'
            }
        }

        stage ('Publish to Nexus') {
            steps {
                nexusArtifactUploader(
                credentialsId: '',
                groupId: 'sms',
                nexusUrl: '<my work domain>:8081/', 
                nexusVersion: 'nexus3',
                protocol: 'http',
                repository: 'sms-staging-rpm',
                version: '*',
                artifacts: [
                    [artifactId: '',
                     classifier: '',
                     file: "${JOB_NAME}-${RELEASE}-${BUILD_NUMBER}.el7.x86_64.rpm",
                     type: 'rpm']
                ])
             }       
        }
    }
}

It goes through everything and in the last stage it gets the variables like it should, except the ${BUILD_NUMER} variable has 2 leading zeros so instead of being “318” it’ll return “00318” and fails to find the correct file.

8

What you have looks like it should definitely work. How did you determine that the filename is different and how is the file name generated in the makefile?

9

I found the filename was different because I was going through the console output. As for the filename, I’m reviewing my makefile and spec file now. Thank you all for your help.