tencent cloud

Feedback

Jenkinsfile Syntax

Last updated: 2023-12-29 11:44:51
    

    Why am I prompted with "cannot pull code" when using ci-init?

    When the ci-init command is used for a build plan (job) created before October 10, 2019, a public/private key pair is created for the user, so they can pull code from repositories in the project. A key pair will not be created when calling ci-init for a build plan created after this date.
    We have built in a credential ID for newly created build plans so users can pull code from repositories. Simply use env.CREDENTIALS_ID as the credentialsId of userRemoteConfigs.

    Old syntax

    pipeline {
    agent any
    stages {
    stage('check out') {
    steps {
    // The old syntax includes ci-init
    sh 'ci-init'
    
    checkout([
    $class: 'GitSCM',
    branches: [[name: env.GIT_BUILD_REF]],
    userRemoteConfigs: [[url: env.GIT_REPO_URL]]
    ])
    }
    }
    }
    }

    New syntax

    pipeline {
    agent any
    stages {
    stage('check out') {
    steps {
    checkout([
    $class: 'GitSCM',
    branches: [[name: env.GIT_BUILD_REF]],
    // Note that the new checkout syntax has the additional credentialsId: env.CREDENTIALS_ID
    userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]
    ])
    }
    }
    }
    }
    As CODING already supports credential management, you should use the more secure credential ID in place of ci-init.
    

    When should I use single or double quotes?

    When using CODING Continuous Integration (CODING-CI), you often need to splice strings or use environment variables as parameters in a Jenkinsfile. Single and double quotes are used differently in a Jenkinsfile. The following demonstrates the differences between the commonly used echo and sh commands.
    pipeline {
    agent any
    environment {
    MY_ENV = 'this is my env'
    }
    stages {
    stage('Test') {
    steps {
    script {
    def MY_ENV = 'define in script'
    
    echo "${env.MY_ENV}"
    // Output: this is my env
    
    echo "\\${env.MY_ENV}"
    // Output: ${env.MY_ENV}
    
    echo "${MY_ENV}"
    // Output: define in script
    
    echo '${MY_ENV}'
    // Output: ${MY_ENV}
    
    sh 'echo ${MY_ENV}'
    // Output: this is my env
    
    sh "echo ${MY_ENV}"
    // Output: define in script
    
    sh "echo ${env.MY_ENV}"
    // Output: this is my env
    }
    }
    }
    }
    }
    echo: When using single quotes, the $ symbols inside are not parsed, but directly included in the output. When using double quotes, MY_ENV in the environment variables is printed.
    sh: When using single quotes, the original text is executed as the sh command normally used in the terminal, so MY_ENV in the environment variables can be printed.
    

    When creating a build plan, what is the difference between choosing to use a Jenkinsfile from a code repository or a static, configured Jenkinsfile?

    When you select a Jenkinsfile from a code repository, the file is stored in the repository. Modifications to the Jenkinsfile require commits to the code repository. If you modify the trigger conditions for continuous integration, integration tasks can still be automatically triggered.
    When you use a static, configured Jenkinsfile, the file is not stored in a code repository, so modifications to the Jenkinsfile do not involve repository updates. During build execution, you should use only static, configured files to ensure the consistency of the build process.
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support