Azure Pipeline中Gradle构建Spring Boot应用无法访问测试资源文件

解决方案1：替换Spring ResourceUtils为ClassPathResource #

ResourceUtils.getFile()对类路径资源的文件系统解析存在环境兼容性问题，改用Spring标准的ClassPathResource可以避免路径解析错误：

static DockerComposeContainer postgresContainer = new DockerComposeContainer(
        new ClassPathResource("docker-compose.yml").getFile());

如果上述代码仍报错（极端场景下资源未被解压到文件系统），改用URI方式初始化：

static DockerComposeContainer postgresContainer = new DockerComposeContainer(
        new File(new ClassPathResource("docker-compose.yml").getURI()));

解决方案2：延迟容器初始化到测试类的setupSpec阶段 #

Spock的静态字段会在类加载时触发初始化，此时Gradle的processTestResources任务（负责将src/test/resources文件复制到build/resources/test）可能还未执行。将容器初始化移到setupSpec()方法中，确保资源已准备完毕：

class YourIntegrationSpec extends Specification {
    DockerComposeContainer postgresContainer

    def setupSpec() {
        postgresContainer = new DockerComposeContainer(new ClassPathResource("docker-compose.yml").getFile())
        postgresContainer.start()
    }

    def cleanupSpec() {
        postgresContainer.stop()
    }
}

解决方案3：添加资源状态验证（排查用） #

在Azure Pipeline中增加步骤，确认资源文件是否被正确复制到build目录，定位问题根源：

在checkout步骤之后、Gradle@2任务之前添加：

- script: |
    # 检查源资源文件是否存在
    ls -la code/src/test/resources/
    # 检查build目录下的资源是否已生成
    mkdir -p code/build/resources/test/ || true
    ls -la code/build/resources/test/
  displayName: Verify resource files

原因分析 #

1. ResourceUtils的局限性：ResourceUtils.getFile()依赖物理文件路径，在CI容器环境中容易出现路径解析偏差，而ClassPathResource是Spring标准的类路径资源访问方式，兼容性更强。
2. 初始化时机冲突：静态字段初始化早于Gradle资源复制任务，导致执行测试时build/resources/test目录下还没有目标文件。
3. Java版本无关：你使用的Java17环境与本次文件找不到的错误无关，核心问题是资源路径解析和初始化时机的冲突。

内容的提问来源于stack exchange，提问作者Tomáš Mika