本地pack CLI可直接传Jar构建镜像，Tekton Buildpacks任务为何失败？

核心预处理逻辑 #

当你执行pack build my/image --path target/my-app-0.0.1-SNAPSHOT.jar时，Pack CLI并不会直接把Jar文件传给/cnb/lifecycle/creator的-app参数——因为creator要求-app必须是目录。Pack会自动完成以下步骤：

• 在本地创建一个临时目录
• 将指定的可执行Jar完整解压到这个临时目录中
• 把解压后的临时目录路径作为-app参数的值，调用/cnb/lifecycle/creator命令

这层封装是Pack CLI专门为单个Jar文件场景做的适配，目的是让用户无需手动解压就能符合Buildpacks生命周期的要求。

为什么传target目录无法识别项目类型？ #

当你传入包含Jar的maven target目录时，Buildpacks的**检测阶段（detect）**会扫描目录内的所有文件。对于Spring Boot应用，Paketo对应的Buildpack需要识别BOOT-INF这类Jar内部的特征结构，但target目录里混杂了.class文件、maven构建元数据、其他临时产物，干扰了检测逻辑，导致无法判定这是一个Spring Boot应用。

而Pack解压后的目录只包含Jar内部的标准结构（BOOT-INF/classes、META-INF等），完全匹配Spring Boot Buildpack的检测规则，所以能顺利完成构建。

和mvn spring-boot:build-image的一致性 #

mvn spring-boot:build-image底层依赖了Spring Boot Buildpacks插件，该插件的处理逻辑和Pack CLI完全对齐：同样会自动解压可执行Jar，再将解压后的目录交给Buildpacks生命周期处理，因此两者的输出结果几乎一致。

Tekton任务的适配方案 #

既然Tekton的Buildpacks任务直接调用creator命令，你可以在任务流程中添加一个预处理步骤：

• 使用unzip或类似工具将目标Jar文件解压到指定的临时目录
• 将解压后的目录路径作为-app参数传入/cnb/lifecycle/creator

这个步骤完全复刻了Pack CLI的内部逻辑，就能解决你遇到的参数报错和项目类型识别问题。

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