Android Studio中.gitlab-ci.yml无法读取GitLab CI/CD设置内用户预定义变量的问题排查

Hey there! Let's figure out why your GitLab CI variables aren't being picked up in your xxx_scan job—since hardcoding works but variable references don't, we can narrow down the issue to how GitLab is handling those variables.

Common Causes & Fixes #

1. Variable Visibility Settings
   GitLab variables have built-in visibility controls that might be blocking access:

   • Head to your project's Settings > CI/CD > Variables
   • Check if your APIKEY/USERKEY variables have the Protect variable checkbox enabled. If yes, confirm your main branch is marked as a protected branch (it’s usually default, but double-check in Settings > Repository > Protected branches). If main isn’t protected, uncheck the Protect variable box for those variables.
   • Verify the Environment scope is set to All (unless you specifically need it restricted to a certain environment). If it’s tied to an environment that doesn’t match your job, the variables won’t be passed through.

2. Variable Name Case Sensitivity
   GitLab CI variables are case-sensitive! Double-check that the variable names in your GitLab project settings exactly match what’s in your .gitlab-ci.yml—so APIKEY in settings can’t be apikey or ApiKey in your config. Even a single lowercase letter will break the reference.

3. Variable Type Mismatch
   If you created the variables as File type instead of Variable type, you can’t reference them directly with $APIKEY. File variables are stored as temporary files, so you’d need to read their content with something like cat $APIKEY instead. Since hardcoding works, this is less likely, but it’s worth confirming the type in your project settings.

4. Debug Variable Values
   Add a quick debug line to your xxx_scan job’s script to see if the variable is being passed at all:

   xxx_scan:
     # ... existing config ...
     script:
       - echo "APIKEY is set to: $APIKEY"  # Add this line first
       - not_relevant_this_is_working
   

   If the output shows APIKEY is set to: (empty), that means visibility is the issue. If it shows **** (masked, which is normal for sensitive variables), the variable is being passed, and the "Bad Org Token" error might be unrelated—but since hardcoding works, this is unlikely.

5. Job-Specific Overrides
   Your xxx_scan job has its own before_script, which replaces the global before_script. While your current before_script only echoes a message, make sure there’s no accidental unset APIKEY or similar command that would overwrite the variable. This is a rare edge case, but worth ruling out.

Quick Recap #

Start with the debug echo line to confirm if the variable is present at all. Then check the visibility and case sensitivity of your variables in GitLab settings—those are the most common culprits for this kind of issue.

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