Travis CI中哪个环境变量可判断当前构建能否访问加密环境变量？

直接用TRAVIS_SECURE_ENV_VARS环境变量来判断是最可靠的方案——它就是专门用来标识当前构建是否能访问加密环境变量的，完美匹配你的需求。

为什么它比其他选项更好？ #

• TRAVIS_PULL_REQUEST有局限性：这个变量只能判断当前是否是拉取请求触发的构建，但Travis文档里明确提到非可信构建“例如”来自外部仓库的PR，这意味着还有其他场景会被标记为非可信（比如某些特殊触发的构建）。只靠这个变量判断，会漏掉这些情况，导致你的脚本在不该使用凭证的环境里尝试调用AWS服务。
• TRAVIS_SECURE_ENV_VARS直接对应加密变量可用性：这个变量的逻辑很简单：当构建是可信的（比如仓库自身的push、tag，或者内部PR），它的值为true，此时加密的AWS凭证可以正常访问；当构建是非可信的（外部PR、其他受限场景），它的值为false，所有加密变量都会被Travis隐藏。

具体实现示例 #

在你的测试脚本或.travis.yml里，可以这样写：

if [ "$TRAVIS_SECURE_ENV_VARS" = "true" ]; then
  # 可信构建：执行依赖AWS凭证的完整测试流程
  echo "Running full tests with AWS credentials..."
  npm run test-with-aws
else
  # 非可信构建：执行无需凭证的轻量测试（比如单元测试、模拟AWS调用的测试）
  echo "Running lightweight tests without AWS credentials..."
  npm run test-unit-only
fi

关于“直接检查加密变量是否存在”的补充 #

这种方法（比如if [ -n "$AWS_ACCESS_KEY_ID" ]; then...）确实能工作，但不如TRAVIS_SECURE_ENV_VARS清晰：

• 它更偏向“检查某个特定变量是否存在”，而不是“当前环境是否允许使用加密变量”
• 如果你以后新增了其他加密变量，不需要修改这个判断逻辑，维护性更好

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