Spring Boot 3.3 with CDS support database error during build process

I am working on a Spring Boot 3.3 project with Java 21 and I am implementing a new CDS (Class Data Sharing) support feature. The application is a standard CRUD application with a REST API that connects to a PostgreSQL database. My application.yml looks like this:

spring:
  datasource:
    url: jdbc:postgresql://host.docker.internal:5433/mydatabase
    username: myuser
    password: secret
  liquibase:
    change-log: classpath:db/changelog/db.changelog-master.xml
    contexts: schema, data
    database-change-log-lock-table: ${liquibase.database-change-log-lock-table}
    database-change-log-table: ${liquibase.database-change-log-table}
  jpa:
    properties:
      hibernate.show_sql: false
      hibernate.format_sql: true
      hibernate.highlight_sql: true
      hibernate.use_sql_comments: true
      hibernate.generate_statistics: false
      hibernate.hbm2ddl.auto: none # validate

audit:
  enable-spring-jpa-listener: true

cache:
  list:
    - name: absence-by-id
      time-to-live: 5m
      enabled: true
  default-time-to-live: 10m
  enable-cache-validation: true

I also have a Dockerfile which is used to build and run the application. The Dockerfile is as follows:

FROM bellsoft/liberica-runtime-container:jdk-21-crac-cds-musl as builder

WORKDIR /home/app
ADD . /home/app/spring-boot-clean-architecture
RUN cd spring-boot-clean-architecture && ./mvnw -Dmaven.test.skip=true -Daether.dependencyCollector.impl=bf clean package

FROM bellsoft/liberica-runtime-container:jdk-21-cds-slim-musl

WORKDIR /home/app
COPY --from=builder /home/app/spring-boot-clean-architecture/target/*.jar app.jar
COPY --from=builder /home/app/spring-boot-clean-architecture/configuration/development/ config/
RUN mv config/application-development.yml config/application.yml
RUN java -Djarmode=tools -jar app.jar extract --layers --launcher

RUN cp -r app/application/* .
RUN cp -r app/dependencies/* .
RUN cp -r app/spring-boot-loader/* .
RUN java -Dspring.aot.enabled=true -XX:ArchiveClassesAtExit=./app/application.jsa -Dspring.context.exit=onRefresh org.springframework.boot.loader.launch.JarLauncher

EXPOSE 8080
ENTRYPOINT exec java $JAVA_OPTS -Dspring.aot.enabled=true -XX:SharedArchiveFile=./app/application.jsa org.springframework.boot.loader.launch.JarLauncher

The Docker build works fine when my PostgreSQL database is running. However, during CI/CD where the database might not be available, the build fails with the following error Caused by: java.net.ConnectException: Connection refused

And the Docker build error:

>>> RUN java -Dspring.aot.enabled=true -XX:ArchiveClassesAtExit=./app/application.jsa -Dspring.context.exit=onRefresh org.springframework.boot.loader.launch.JarLauncher
--------------------
ERROR: failed to solve: process "/bin/sh -c java -Dspring.aot.enabled=true -XX:ArchiveClassesAtExit=./app/application.jsa -Dspring.context.exit=onRefresh org.springframework.boot.loader.launch.JarLauncher" did not complete successfully: exit code: 1

I am considering the following approaches but am unsure which one is best:

1. Use a separate application.yml for CI/CD: Configure an H2 database to ensure the application starts without needing a real PostgreSQL instance.
2. Autoconfigure exclusions: Exclude DataSourceAutoConfiguration and JpaRepositoriesAutoConfiguration, but this leads to errors because my repository beans require an entity manager. 3.Any other approach: Is there another way to handle this situation more effectively?

What is the best practice for handling database dependencies during the CI/CD build process to avoid the above errors or to approach Spring Boot with CDS support?

As Scott mentiond in the comments, there are options for test-run configuration for JPA, JDBC, R2DBC, Spring Batch, Liquibase,... that are documented right here https://github.com/spring-projects/spring-lifecycle-smoke-tests/blob/main/README.adoc#training-run-configuration

Using those in my application.yml used for this CDS run established successful run and enabled me to utilize CDS support. Once again, thanks Scott!