我来给你梳理几种适配你场景的可行方案，刚好对应你用自托管Docker容器运行GitLab CI移动项目的需求：

1. 全局变量注入（最简单直接） #

你可以直接在项目的.gitlab-ci.yml开头定义variables区块，这里的变量会自动注入到GitLab CI启动的Docker容器环境中，容器初始化阶段就能拿到这些值，完全满足你在项目构建步骤前配置主机环境的需求。

举个实际配置的例子：

image: eu.gcr.io/android-build-image:1.0.0
variables:
  # 这里定义你要传递的自定义运行时变量
  ANDROID_BUILD_PROFILE: "debug"
  CUSTOM_HOST_CONFIG: "internal"

当容器启动后，这些变量就会成为容器的系统环境变量。如果你的自定义Docker镜像里有初始化脚本（比如entrypoint.sh），可以直接读取这些变量来完成配置，比如：

# 假设这是你Dockerfile里指定的entrypoint脚本内容
if [ -n "$CUSTOM_HOST_CONFIG" ]; then
  echo "配置主机环境：$CUSTOM_HOST_CONFIG"
  # 在这里编写你的配置逻辑，比如修改系统配置文件、调整环境参数等
fi

2. 针对特定作业/阶段传递变量 #

如果某些变量只需要在特定的CI作业或阶段中生效，你不用全局定义，直接在对应的作业区块里添加variables即可：

image: eu.gcr.io/android-build-image:1.0.0

stages:
  - build
  - test

build_debug:
  stage: build
  variables:
    BUILD_TYPE: "debug"
  script:
    - ./gradlew assembleDebug

build_release:
  stage: build
  variables:
    BUILD_TYPE: "release"
  script:
    - ./gradlew assembleRelease

这样不同的作业容器会拿到对应的变量，能针对性地完成环境配置。

3. 结合Dockerfile的ARG与ENV（进阶场景） #

如果你希望在构建自定义Docker镜像时预留变量占位，然后在CI运行容器时动态赋值，可以结合Dockerfile的ARG和ENV指令：

首先在你的Dockerfile里定义构建时变量，并转为运行时环境变量：

# 自定义Dockerfile中的配置
ARG DEFAULT_BUILD_PROFILE=debug
ENV BUILD_PROFILE=$DEFAULT_BUILD_PROFILE

之后在.gitlab-ci.yml里定义同名变量时，会自动覆盖Dockerfile中设置的默认值，容器初始化时就会使用你传递的新值。

注意事项 #

如果传递的是敏感信息（比如密钥、配置密码），不要直接写在.gitlab-ci.yml里，建议在GitLab项目的「设置 → CI/CD → 变量」中配置，标记为受保护变量或掩码变量，避免在CI日志中明文暴露。

备注：内容来源于stack exchange，提问作者Bogdan Zurac