Bitbucket Pipeline使用Gradle构建zip包时.env变量配置方案问询

最佳实践说明 #

用Bitbucket自带的仓库变量/部署变量是该场景的标准最佳实践，无需将环境配置（尤其是后续可能新增的敏感配置）提交到代码仓库，符合配置和代码分离的规则，也方便多环境差异化配置的灵活调整。

具体实现步骤 #

• 第一步：在Bitbucket仓库配置对应变量
  进入仓库设置 > 仓库变量页面，将需要动态调整的变量按.env中的键名作为变量名存储对应值，敏感值勾选保密选项即可，配置完成后所有流水线步骤都可以直接读取到这些变量。
  如果是多环境部署场景，建议使用Bitbucket的部署变量，不同环境配置不同值，调整更灵活。
• 第二步：在流水线配置中增加.env生成逻辑
  在你的bitbucket-pipelines.yml的构建步骤中，执行Gradle打包之前新增生成.env文件的脚本，示例配置参考如下：

pipelines:
  default:
    - step:
        name: 构建并生成Zip包
        image: openjdk:11 # 按你的项目需要的JDK版本调整
        script:
          # 生成.env配置文件
          - echo "NETWORK_NAME=$NETWORK_NAME" > .env
          - echo "GROVE_ZIP_PATH=./build" >> .env
          - echo "GROVE_ZIP_FILENAME=zipName.zip" >> .env
          - echo "HOST=$HOST" >> .env
          - echo "PORT_MAIN=8070" >> .env
          - echo "PORT_SEARCH=8074" >> .env
          # 给gradlew增加执行权限（Linux runner环境默认无执行权限）
          - chmod +x gradlew
          # 执行Gradle打包指令
          - ./gradlew zipName
        artifacts:
          # 打包后的zip包可以配置为制品方便后续下载使用
          - build/zipName.zip

如果配置的变量数量较多，可以用批量生成逻辑减少重复代码：

# 批量生成.env脚本
ENV_KEYS=("NETWORK_NAME" "GROVE_ZIP_PATH" "GROVE_ZIP_FILENAME" "HOST" "PORT_MAIN" "PORT_SEARCH")
> .env # 清空已有的.env文件
for key in "${ENV_KEYS[@]}"; do
  echo "$key=${!key}" >> .env
done

注意事项 #

• 固定不变的非敏感配置可以直接硬编码在.env生成脚本中，无需存入仓库变量减少配置成本
• 所有敏感类配置（如数据库密码、API密钥等）必须勾选变量的保密选项，避免明文泄露在流水线日志中
• 将本地使用的.env文件加入.gitignore，避免误提交到代码库

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