Jenkins自动拉取代码并构建打包的核心是凭据、路径、执行上下文三者严格匹配：SSH需用Jenkins用户生成密钥并手动首次连接以写入known_hosts，HTTPS需用带repo权限的PAT；构建命令须确保Jenkins用户环境中有正确配置的JDK/Maven/Node及Docker访问权限，且工作目录存在对应配置文件。
Jenkins 要实现自动拉取代码并构建打包，核心不是“能不能”，而是**凭据、路径、执行上下文三者是否对得上**。配错任意一环，git clone 就会卡在认证失败或权限拒绝，mvn package 或 npm run build 就会报命令未找到或找不到 pom.xml/package.json。
Git 拉取失败：凭据和 known_hosts 是最大雷区
Jenkins 进程实际以某个系统用户身份运行（常见是 jenkins 用户，非 root），它必须能用该用户身份完成 SSH 连接或 HTTPS 认证。
- 用 SSH 方式拉 Git 时，必须在 Jenkins 所在服务器上，用 Jenkins 进程对应用户（如
jenkins）生成密钥对，并把公钥加到代码仓库（GitHub/GitLab/云效等）的 Deploy Keys 或 SSH Keys 中 - 首次 SSH 连接目标 Git 主机（如
git@github.com）时，会提示 “The authenticity of host … can’t be established”，此时必须由 Jenkins 用户手动执行一次ssh -T git@github.com并输入yes，否则known_hosts文件不会生成，后续构建必然失败，报错类似No RSA host key is known for github.com - HTTPS 方式需配置用户名+密码或 Personal Access Token（PAT）作为凭据，且 Token 必须有
repo权限；旧式密码在 GitHub 已不可用
构建命令执行失败：环境变量和工作目录不匹配
Jenkins 默认在项目工作空间（如 /var/jenkins_home/workspace/my-project）下执行构建步骤，但 JDK、Maven、Node.js 等工具未必就绪。
- 确保 Jenkins 全局工具配置中已声明 JDK 和 Maven 的安装路径（
Global Tool Configuration → JDK / Maven），不要依赖系统 PATH —— 容器或服务账户下 PATH 往往不同 - 自由风格项目中，
Execute shell步骤里别写mvn clean package就完事；应先确认当前目录是否有pom.xml：ls -l pom.xml || echo "pom.xml not found!"，避免静默失败 - 前端项目用
npm，需提前在全局配置中添加 NodeJS 安装（通过 NodeJS 插件），并在构建步骤中勾选 “Provide Node & npm bin/ folder to PATH”
Docker 构建或镜像推送前，Jenkins 必须能调用 docker 命令
如果构建目标是 Docker 镜像，Jenkins 进程必须属于 docker 用户组，且 docker.sock 可访问。
- 宿主机上执行：
sudo usermod -aG docker jenkins（假设 Jenkins 以jenkins用户运行） - 若 Jenkins 运行在容器中，需挂载宿主机
/var/run/docker.sock和/usr/bin/docker（或使用docker:dind模式） - 验证方式：进 Jenkins 脚本执行
docker version && docker info | grep 'Default Runtime'，不能只看which docker - 私有 Harbor 推送前，务必先在 Jenkins 机器上用对应用户手动
docker login -u xxx -p yyy harbor.example.com，否则docker push会因未授权失败
真正卡住人的，往往不是流程没走通，而是 Jenkins 用户看不见、摸不到、连不上——它不像你本地终端那样有完整环境和交互式信任链。每一步都要站在它的视角去验证，而不是“理论上应该可以”。
