我在配置bitbucket管道时无法获取任何可以获取应用版本名称的字段。尝试以下方法:在Repository变量中定义值,但这会导致每次都需要手动更新版本。在项目级build.gradle中设置变量并在管道中访问-不起作用
project.ext.set("my_lib_version", "2.1.0")
//在管道中
script: - echo $my_lib_version
ajsxfq5m1#
在Repository变量中定义值,但这会导致每次都需要手动更新版本。当然,尽管这在技术上可行,但实际上并不可行。有时setting the variable via the REST Api可以做到这一点。在项目级build.gradle中设置变量并在管道中访问-不起作用
是的,它不起作用。原因是构建管理器(gradle?)只能为当前构建设置环境变量-而不能为父管道脚本设置环境变量。相反,您需要写入到某个文件中,然后将该文件导出为pipeline artifact。然后,您可以从文件内容中设置脚本环境变量。这在现有的Q&A材料 * Make variable visible across steps in Bitbucket pipelines? * 中已经介绍过。如果该值已经存在于仓库中的文件中(或者git中,例如标签或提交消息),则与从文件中阅读相同的原则适用,但只需使用命令替换。此外,由于该值已经是仓库的一部分,因此不需要工件。就我个人而言,我更喜欢这样的工作流,其中版本相关的信息来自仓库版本本身,这样构建是可重复的,或者至少是稳定的(构建环境不容易改变结果)。例如,通过创建和推送git标签来发布,管道变量的值为$BITBUCKET_TAG。典型的例子是使用版本号作为标签名称,例如在您的案例中为2.1.0。然后发布开发人员可以签署并推送标签,处理标签的管道需要具有已标记的修订版本的绿色构建。然后只需发布修订版本的工件。有关在git中使用标记的更多信息,请参阅git-tag(1) manpage。
$BITBUCKET_TAG
2.1.0
git-tag(1)
sxpgvts32#
如果versionName是硬编码在app/build.gradle文件中的,那么你可以使用bash/shell命令提取字符串,如awk和perl,这些命令在Linux Docker机器上可用:
versionName
app/build.gradle
awk
perl
android { defaultConfig { ... versionName "2.1.0" ... } }
在yml文件中,使用awk或perl从app/build.gradle中提取versionName字符串:
script: - export APP_VERSION_NAME=$(awk '/versionName .*"/{gsub(/\"/,"",$2);print $2}' "app/build.gradle") - echo "APP_VERSION_NAME = $APP_VERSION_NAME" # This prints: 2.1.0 - export APP_VERSION_NAME2=$(perl -nle 'print $& while m{(?<=versionName ").*?(?=")}g' "app/build.gradle") - echo "APP_VERSION_NAME2 = $APP_VERSION_NAME2" # This prints: 2.1.0
如果versionName是使用环境变量或其他字符串模板自动生成的,则必须首先构建代码,然后从自动生成的BuildConfig.java文件中提取字符串:
BuildConfig.java
project.ext.my_lib_version = "2.1.0" android { defaultConfig { ... versionName "${project.ext.my_lib_version}-debug" ... } }
构建代码后,自动生成的BuildConfig.java文件将包含真实的字符串:
public final class BuildConfig { ... public static final String VERSION_NAME = "2.1.0-debug"; ... }
在yml文件中,使用awk或perl从BuildConfig.java中提取versionName字符串:
script: # Build the Android app - ./gradlew assembleDebug # There may be multiple 'BuildConfig.java' files. Get the path of the # the first 'BuildConfig.java' file which is closest to the root folder - BUILD_CONFIG_FILE_PATH=$(find "$(pwd -P)" -name BuildConfig.java | awk '{ print length, $0 }' | sort -n -s | cut -d" " -f2- | head -1) - echo "BUILD_CONFIG_FILE_PATH = $BUILD_CONFIG_FILE_PATH" - export APP_VERSION_NAME=$(awk '/VERSION_NAME/{gsub(/\"/,"",$7) ; gsub(/;/,"",$7) ; print $7}' $BUILD_CONFIG_FILE_PATH) - echo "APP_VERSION_NAME = $APP_VERSION_NAME" # This prints: 2.1.0-debug - export APP_VERSION_NAME2=$(perl -nle 'print $& while m{(?<=VERSION_NAME = ").*?(?=")}g' $BUILD_CONFIG_FILE_PATH) - echo "APP_VERSION_NAME2 = $APP_VERSION_NAME2" # This prints: 2.1.0-debug
BUILD_CONFIG_FILE_PATH
gsub
2条答案
按热度按时间ajsxfq5m1#
在Repository变量中定义值,但这会导致每次都需要手动更新版本。
当然,尽管这在技术上可行,但实际上并不可行。
有时setting the variable via the REST Api可以做到这一点。
在项目级build.gradle中设置变量并在管道中访问-不起作用
是的,它不起作用。原因是构建管理器(gradle?)只能为当前构建设置环境变量-而不能为父管道脚本设置环境变量。
相反,您需要写入到某个文件中,然后将该文件导出为pipeline artifact。
然后,您可以从文件内容中设置脚本环境变量。这在现有的Q&A材料 * Make variable visible across steps in Bitbucket pipelines? * 中已经介绍过。
如果该值已经存在于仓库中的文件中(或者git中,例如标签或提交消息),则与从文件中阅读相同的原则适用,但只需使用命令替换。此外,由于该值已经是仓库的一部分,因此不需要工件。
就我个人而言,我更喜欢这样的工作流,其中版本相关的信息来自仓库版本本身,这样构建是可重复的,或者至少是稳定的(构建环境不容易改变结果)。例如,通过创建和推送git标签来发布,管道变量的值为
$BITBUCKET_TAG
。典型的例子是使用版本号作为标签名称,例如在您的案例中为
2.1.0
。然后发布开发人员可以签署并推送标签,处理标签的管道需要具有已标记的修订版本的绿色构建。然后只需发布修订版本的工件。有关在git中使用标记的更多信息,请参阅
git-tag(1)
manpage。sxpgvts32#
如果
versionName
是硬编码在app/build.gradle
文件中的,那么你可以使用bash/shell命令提取字符串,如awk
和perl
,这些命令在Linux Docker机器上可用:1. app/build.gradle包含硬编码的versionName:
在yml文件中,使用
awk
或perl
从app/build.gradle
中提取versionName
字符串:如果
versionName
是使用环境变量或其他字符串模板自动生成的,则必须首先构建代码,然后从自动生成的BuildConfig.java
文件中提取字符串:2. app/build.gradle包含字符串模板:
构建代码后,自动生成的
BuildConfig.java
文件将包含真实的字符串:在yml文件中,使用
awk
或perl
从BuildConfig.java
中提取versionName
字符串:3.关于这些命令及其工作原理的更多信息和参考:
awk
和perl
从文本文件中提取字符串:如何在bitbucket-pipelines.yml文件中使用build.gradle文件中的版本BUILD_CONFIG_FILE_PATH
:Sort a text file by line length including spacesgsub
从awk
输出中删除多个字符:Remove duplicate characters using AWK gsub()