GitLab Runner中Docker构建失败本地正常：Spring Boot GraalVM原生编译问题

问题背景 #

本地使用以下Dockerfile构建Spring Boot原生镜像完全正常，但在GitLab Runner中执行时，报错JAVA_HOME is not defined correctly. We cannot execute /opt/graalvm-ce-java17-22.3.1/bin/java。通过修改maven wrapper脚本排查，确认JAVACMD文件存在但不可执行。

Dockerfile内容：

FROM ghcr.io/graalvm/graalvm-ce:22.3.1 AS buildnative

WORKDIR /app

COPY mvnw pom.xml ./
COPY .mvn/ .mvn
COPY src ./src
RUN ./mvnw clean package -Pnative

FROM ubuntu:23.04
EXPOSE 8080
COPY --from=buildnative /app/target/spring-boot-project /build/app
CMD ["/build/app"]

可能的解决方向 #

1. 检查架构兼容性 #

若本地环境与GitLab Runner的CPU架构不一致（比如本地是x86_64，Runner是arm64，或反之），GraalVM镜像中的二进制文件会因架构不匹配无法执行，表现为“文件存在但不可执行”。

• 操作步骤：
  • 在Dockerfile的buildnative阶段添加RUN arch命令，查看构建环境的架构
  • 确认GitLab Runner的架构，选择对应架构的GraalVM镜像（比如arm64版本的镜像为ghcr.io/graalvm/graalvm-ce:22.3.1-jdk17-arm64）

2. 手动修复GraalVM二进制文件权限 #

虽然官方镜像默认配置了正确权限，但GitLab Runner的环境可能存在权限继承异常，可手动确保Java二进制文件的可执行性：

• 修改Dockerfile的buildnative阶段，在执行mvnw前添加权限修复命令：

  RUN chmod +x $JAVA_HOME/bin/java
  RUN ./mvnw clean package -Pnative
  

3. 排查GitLab Runner的Docker安全配置 #

部分GitLab Runner配置了严格的安全选项，可能限制了二进制文件的执行：

• 检查Runner的config.toml，查看是否启用了no-new-privileges = true或类似的seccomp/selinux限制
• 临时禁用这些安全选项测试，确认是否是权限限制导致的问题

4. 跳过Maven wrapper直接使用Maven #

避免wrapper脚本的路径解析问题，直接使用GraalVM镜像内置的Maven（或手动安装）执行构建：

• 修改buildnative阶段的命令：

  RUN apt-get update && apt-get install -y maven
  RUN mvn clean package -Pnative
  

5. 增加调试命令排查环境细节 #

在Dockerfile中添加更多调试命令，明确构建环境的状态：

• 在执行mvnw前添加：

  RUN echo "JAVA_HOME: $JAVA_HOME"
  RUN ls -l $JAVA_HOME/bin/java
  RUN id
  RUN mount
  

  通过这些输出确认环境变量、文件权限、用户身份和挂载情况是否正常

内容的提问来源于stack exchange，提问作者vandaele mathias