Jenkins Pipeline Script

Script는 두가지 방식이 있다.

1. Scripted
2. Declarative

아래는 Scripted 방식으로 기술한 Pipeline Script

함께 사용된 도구들

• Git Parameters
• Dockerfile
• Docker Private Registry
• Rancher 배포 curl
• Gradle(Groovy)
• Jenkins Credentials
• Linux shell

Scripted

node {
    //git_branch = sed -i 's|origin/|'"${params.GIT_BRANCH}"'|'
    git_branch = "${params.GIT_BRANCH.replace("origin/", "")}" 
    stage("Parameter Check") {  
        echo 'Start'
        echo "${env.JOB_NAME}"
        echo "${params.GIT_BRANCH}"
        echo "${git_branch}"
        
    }
    stage ('Clone'){
        git branch: "${git_branch}", credentialsId: 'git_erp_user', url: 'http://10.20.101.xxx:8111/hds_api/hds_api_erp_core.git'
    }
    stage("Compilations") {
        sh "chmod +x gradlew"
        sh "./gradlew :api:clean :api:build -x test"
    }
     
    stage("Staging") {
        // sh "pid=\$(lsof -i:8989 -t); kill -TERM \$pid " 
        //   + "|| kill -KILL \$pid"
        // withEnv(['JENKINS_NODE_COOKIE=dontkill']) {
        //     sh 'nohup ./mvnw spring-boot:run -Dserver.port=8989 &'
        // }   
        sh "docker build -t hds_api_erp:${BUILD_NUMBER} ./api"
        sh "docker tag hds_api_erp:${BUILD_NUMBER} 10.20.101.xxx:5000/hds_api_erp"
        sh "docker push 10.20.101.xxx:5000/hds_api_erp"
        
        // develop 
        sh '''
        curl -u "${HOMS_CATTLE_ACCESS_KEY}:${HOMS_CATTLE_SECRET_KEY}" \
        -X POST \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        "https://10.20.101.xxx/v3/project/c-266jz:p-d7tbd/workloads/daemonset:erp-dev:hds-api-erp-${git_branch}?action=redeploy --insecure"
        '''

        // release
        sh '''
        curl -u "${HOMS_CATTLE_ACCESS_KEY}:${HOMS_CATTLE_SECRET_KEY}" \
        -X POST \
        -H 'Accept: application/json' \
        -H 'Content-Type: application/json' \
        "https://10.20.101.xxx/v3/project/c-qrsb8:p-wqt98/workloads/daemonset:erp:hds-api-erp-${git_branch}?action=redeploy --insecure"
        '''
    }
}

• 기본 전역 변수들
• BRANCH_NAME For a multibranch project, this will be set to the name of the branch being built, for example in case you wish to deploy to production from master but not from feature branches; if corresponding to some kind of change request, the name is generally arbitrary (refer to CHANGE_ID and CHANGE_TARGET). CHANGE_ID For a multibranch project corresponding to some kind of change request, this will be set to the change ID, such as a pull request number, if supported; else unset. CHANGE_URL For a multibranch project corresponding to some kind of change request, this will be set to the change URL, if supported; else unset. CHANGE_TITLE For a multibranch project corresponding to some kind of change request, this will be set to the title of the change, if supported; else unset. CHANGE_AUTHOR For a multibranch project corresponding to some kind of change request, this will be set to the username of the author of the proposed change, if supported; else unset. CHANGE_AUTHOR_DISPLAY_NAME For a multibranch project corresponding to some kind of change request, this will be set to the human name of the author, if supported; else unset. CHANGE_AUTHOR_EMAIL For a multibranch project corresponding to some kind of change request, this will be set to the email address of the author, if supported; else unset. CHANGE_TARGET For a multibranch project corresponding to some kind of change request, this will be set to the target or base branch to which the change could be merged, if supported; else unset. CHANGE_BRANCH For a multibranch project corresponding to some kind of change request, this will be set to the name of the actual head on the source control system which may or may not be different from BRANCH_NAME. For example in GitHub or Bitbucket this would have the name of the origin branch whereas BRANCH_NAME would be something like PR-24. CHANGE_FORK For a multibranch project corresponding to some kind of change request, this will be set to the name of the forked repo if the change originates from one; else unset. TAG_NAME For a multibranch project corresponding to some kind of tag, this will be set to the name of the tag being built, if supported; else unset. TAG_TIMESTAMP For a multibranch project corresponding to some kind of tag, this will be set to a timestamp of the tag in milliseconds since Unix epoch, if supported; else unset. TAG_UNIXTIME For a multibranch project corresponding to some kind of tag, this will be set to a timestamp of the tag in seconds since Unix epoch, if supported; else unset. TAG_DATE For a multibranch project corresponding to some kind of tag, this will be set to a timestamp in the format as defined by java.util.Date#toString() (e.g., Wed Jan 1 00:00:00 UTC 2020), if supported; else unset. BUILD_NUMBER The current build number, such as "153" BUILD_ID The current build ID, identical to BUILD_NUMBER for builds created in 1.597+, but a YYYY-MM-DD_hh-mm-ss timestamp for older builds BUILD_DISPLAY_NAME The display name of the current build, which is something like "#153" by default. JOB_NAME Name of the project of this build, such as "foo" or "foo/bar". JOB_BASE_NAME Short Name of the project of this build stripping off folder paths, such as "foo" for "bar/foo". BUILD_TAG String of "jenkins-${JOB_NAME}-${BUILD_NUMBER}". All forward slashes ("/") in the JOB_NAME are replaced with dashes ("-"). Convenient to put into a resource file, a jar file, etc for easier identification. EXECUTOR_NUMBER The unique number that identifies the current executor (among executors of the same machine) that’s carrying out this build. This is the number you see in the "build executor status", except that the number starts from 0, not 1. NODE_NAME Name of the agent if the build is on an agent, or "master" if run on master NODE_LABELS Whitespace-separated list of labels that the node is assigned. WORKSPACE The absolute path of the directory assigned to the build as a workspace. WORKSPACE_TMP A temporary directory near the workspace that will not be browsable and will not interfere with SCM checkouts. May not initially exist, so be sure to create the directory as needed (e.g., mkdir -p on Linux). Not defined when the regular workspace is a drive root. JENKINS_HOME The absolute path of the directory assigned on the master node for Jenkins to store data. JENKINS_URL Full URL of Jenkins, like http://server:port/jenkins/ (note: only available if Jenkins URL set in system configuration) BUILD_URL Full URL of this build, like http://server:port/jenkins/job/foo/15/ (Jenkins URL must be set) JOB_URL Full URL of this job, like http://server:port/jenkins/job/foo/ (Jenkins URL must be set) SCM-specific variables such as GIT_COMMIT are not automatically defined as environment variables; rather you can use the return value of the checkout step. As an example of loading variable values from Groovy: mail to: 'devops@acme.com', subject: "Job '${JOB_NAME}' (${BUILD_NUMBER}) is waiting for input", body: "Please go to ${BUILD_URL} and verify the build"