1. 产品简介
  2. 快速开始
  3. 编写构建流程
  4. 配置构建计划
  5. 构建环境依赖包
  6. 构建制品
  7. 构建节点
  8. 管理构建计划
  9. 系统插件
  10. 自定义团队插件
  11. 最佳实践
  12. 常见问题
  13. 词汇表
持续集成 / 常见问题 / Jenkinsfile 相关问题

Jenkinsfile 相关问题

为什么使用 ci-init 时提示无法拉取代码

2019 年 10 月 10 日 之前创建的构建计划( Job )中的 ci-init 命令会为用户创建一对公私钥,并使其能够拉取项目中的代码仓库。之后创建的构建计划在调用 ci-init 时,将不会创建拉取代码的公私钥对了。

在此之后新创建的构建计划, 我们都会为用户内置一个可以用于拉取对应代码仓库的凭据 ID,直接使用 env.CREDENTIALS_ID 作为 userRemoteConfigs 的 credentialsId 即可。

旧的语法:

pipeline {
    agent any
        stages {
        stage('检出') {
            steps {
                // 旧版本的语法含有 ci-init 
                sh 'ci-init'

                checkout([
                    $class: 'GitSCM', 
                    branches: [[name: env.GIT_BUILD_REF]],
                    userRemoteConfigs: [[url: env.GIT_REPO_URL]]
                ])
            }
        }
    }
}

新的语法:

pipeline {
    agent any
        stages {
        stage('检出') {
            steps {
                checkout([
                    $class: 'GitSCM', 
                    branches: [[name: env.GIT_BUILD_REF]],
                    // 请注意新版的检出语法比旧版新增了 credentialsId: env.CREDENTIALS_ID
                    userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]
                ])
            }
        }
    }
}

CODING 目前已经支持了凭据管理,我们建议用户使用更安全的凭据 ID 来代替之前的 ci-init 操作。

关于凭据如果您想了解更多可以参考《凭据管理》

单引号和双引号用法差异是什么

使用 CODING 持续集成时经常需要在 Jenkinsfile 内拼接字符串或使用环境变量作为参数, Jenkinsfile 中的单引号和双引号在使用时,会有些许差异, 以下演示常用的 echo 与 sh 两个命令的差异。

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}"
                    // 输出内容为 this is my env

                    echo "\${env.MY_ENV}"
                    // 输出内容为 ${env.MY_ENV}

                    echo "${MY_ENV}"
                    // 输出内容为 define in script

                    echo '${MY_ENV}'
                    // 输出内容为 ${MY_ENV}

                    sh 'echo ${MY_ENV}'
                    // 输出内容为 this is my env

                    sh "echo ${MY_ENV}"
                    // 输出内容为 define in script

                    sh "echo ${env.MY_ENV}"
                    // 输出内容为 this is my env
                }
            }
        }
    }
}

echo 在使用单引号时,并不会解析里面的 $ 符号,而是直接输出原文;在使用双引号时,会打印出环境变量里的 MY_ENV。

sh 在使用单引号时,将原文当作我们平时在终端里 sh 的命令一样执行,所以可以打印出环境变量里的 MY_ENV。

持续集成的配置来源区别是什么?

在创建构建计划时选择使用 代码仓库中的 Jenkinsfile静态配置的 Jenkinsfile 有什么区别?

选择使用代码仓库中的 Jenkinsfile 后,该文件将存储至代码仓库中。修改 Jenkinsfile 意味着需在代码仓库中提交修改记录,若修改持续集成的触发条件,还可以自动触发集成任务。

使用静态配置的 Jenkinsfile 后,该文件将不会存储在代码仓库中,修改 Jenkinsfile 不会更新代码仓库内容,执行构建时将统一使用静态配置,保障构建流程的一致性。

如何自定义变量?

  • 使用 enviroment 语法生成

    以生产日期变量为例:

environment {
    DATE2 = sh(returnStdout: true, script: 'date +%Y%m').trim()
  }

  • 在 steps 中定义全局/局部变量

    全局:执行 pipeline 脚本并在 script 框内定义

script {
          env.cusversionall=sh(returnStdout: true, script: 'date +%Y%m').trim()          echo "${cusversionall}"}

局部:仅在步骤中生效

script {
          def cusversion=sh(returnStdout: true, script: 'date +%Y%m').trim()          echo "${cusversion}"}

如何查看工作空间目录?

在流程配置中的 shell 步骤添加 pwd 命令行进行查看。

远程 SSH 执行命令时环境变量不生效

由于在使用构建机连接远程 SSH 时使用了“非交互非登录式”连接,因此无法引用远程机器的 /etc/profile~/.bashrc 等文件配置中的环境变量。

你可以参考以下示例,使用 export 命令再设置变量且用 && 符号连续输入命令。

export PATH=/opt/jdk1.8.0_281/bin:$PATH && java -version

上一篇定时同步私有代码库
最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?

您希望我们如何改进?

工单咨询