如何在Harness中用Bash声明环境变量并作为后续步骤执行条件

第一步：通过Bash声明条件环境变量 #

在Harness流水线中添加一个Bash Shell Script步骤，根据业务条件设置布尔型变量。以下是两种常用的变量暴露方式：

方式1：设置阶段内可用的环境变量 #

适合变量仅在当前阶段后续步骤中使用，脚本示例：

# 示例：根据当前分支是否为release分支设置变量
if [ "$HARNESS_BRANCH" == "release/*" ]; then
  RUN_VALIDATION=false
else
  RUN_VALIDATION=true
fi

# 将变量写入Harness内置环境文件，供后续步骤读取
echo "RUN_VALIDATION=$RUN_VALIDATION" >> $HARNESS_ENV_FILE

方式2：设置流水线级全局变量 #

适合变量需要跨阶段使用的场景，使用Harness CLI命令设置：

# 示例：根据构建产物大小设置变量
if [ $(du -sh ./dist | cut -f1) == "100M" ]; then
  TRIGGER_COMPRESS=false
else
  TRIGGER_COMPRESS=true
fi

# 设置流水线级变量，全流水线可见
harness-cli variable set --name TRIGGER_COMPRESS --value "$TRIGGER_COMPRESS"

第二步：配置仅当变量为false时执行的步骤 #

添加目标步骤（如Bash脚本、部署、通知等）后，通过Harness的条件控制实现仅在变量为false时执行：

1. 选中目标步骤，进入Advanced配置项
2. 在Condition字段中填写对应表达式：
   • 若使用阶段环境变量：${env.RUN_VALIDATION} == "false"
   • 若使用流水线全局变量：${pipeline.variables.TRIGGER_COMPRESS} == "false"

以Bash步骤为例，执行脚本可参考：

echo "执行仅当变量为false时的逻辑"
# 替换为实际操作，比如跳过验证流程、触发特殊部署逻辑等

最佳实践 #

• 变量命名规范：采用大写字母加下划线的格式（如RUN_VALIDATION），避免与Harness内置变量（如$HARNESS_COMMIT_MESSAGE）冲突
• 注释清晰化：在变量声明脚本中添加注释，说明变量值的判断逻辑，降低后续维护成本
• 作用域合理选择：阶段内使用优先选环境变量，跨阶段共享则用流水线全局变量
• 全场景测试：分别测试变量为true和false的场景，验证步骤执行符合预期
• 依赖内置变量：尽量使用Harness提供的内置变量作为条件输入，减少硬编码值，提升流水线灵活性

内容的提问来源于stack exchange，提问作者Jessica