如何在Jelastic JPS清单中使用GitLab个人访问令牌访问私有仓库

核心问题根因 #

• GitHub 私有 raw 拉取支持用 ?access_token= 查询参数传认证，但 GitLab 的安全设计逻辑完全不同：原生 raw 端点既不认 access_token 这个参数名，也默认不允许通过查询参数传访问令牌做认证，直接套 GitHub 的写法肯定失效。
• 你之前碰到的 127 报错，是两个问题叠加导致的：
  1. 自行拼接的 API 路径带了 %2F URL 编码、多层斜杠、管道符这些特殊字符，Jelastic 默认用 dash 当 shell，处理带引号的长命令字符串时容易解析错乱，直接把整段命令识别成了一个带花括号的文件名
  2. 那段 API 路径在变量替换的时候，原本编码的 %2F 被自动解码成了普通斜杠，GitLab API 直接识别错路径结构

最简洁的实现（完全替代当前的 API 写法） #

根本不需要绕去复杂的 API 端点，你之前用的 raw 基础路径完全可以继续沿用，只需要在 curl/wget 请求里加一个 GitLab 识别的认证头即可，和你之前用公共仓库的写法几乎无差异：

# 原来的 raw 基础路径完全保留，无需修改
baseUrl: https://www.my-gitlab.com/my-company/my-project/my-repo/-/raw/master

onInstall:
  - cmd:
    # 原有 curl 命令仅多添加一个认证头参数，其余逻辑和公共仓库写法一致
    - curl -fsSL -H "PRIVATE-TOKEN: ${settings.accessToken}" ${baseUrl}/my-folder/my-script.sh | /bin/sh
    # 原有 wget 命令也仅多添加一个认证头参数
    - wget --header="PRIVATE-TOKEN: ${settings.accessToken}" ${baseUrl}/my-folder/my-script.sh -O my-script.sh

这种写法没有复杂的 URL 编码、没有多层拼接的长 API 路径，直接规避了 Jelastic 的 shell 解析问题，比现有 API 写法简洁很多。

JPS 依赖拉取的兼容写法 #

Jelastic 自带的 install.jps 逻辑是平台后台直接发 HTTP 请求拉取文件，不支持自定义请求头，这个时候不能用请求头传认证，需要用 GitLab 支持的查询参数方式，注意参数名是 GitLab 专属的 private_token，不是 GitHub 用的 access_token：

onInstall:
  install:
    # 继续使用原有 raw 路径，无需切换为 API 地址，仅修正查询参数名即可正常认证
    jps: ${baseUrl}/jelastic/tools.jps?private_token=${settings.accessToken}

避坑提醒 #

• 在 GitLab 生成的访问令牌，必须勾选 read_repository 权限，否则会直接返回 403 无权限错误
• 如果你的 GitLab 实例开启了双因素认证，不能用账号密码做认证，必须使用生成的访问令牌
• Jelastic 环境下写 shell 命令时，尽量不要把带特殊字符的长命令（比如带编码、多层管道的内容）直接拼在一行里，容易触发解析错误；如果脚本逻辑复杂，建议先把文件拉到本地存为脚本文件，再执行，不要直接管道传内容给 shell

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