Spring boot image build

Skill arconia-io/agent-skills/skills/spring-boot-image-build

Agent Skills for the Java, Spring Boot, and Arconia ecosystem, published as OCI artifacts and consumable via the Arconia CLI or any tool supporting the Agent Skills OCI Artifacts Specification.

Install

npx -y skills add arconia-io/agent-skills --skill spring-boot-image-build

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build container images for Spring Boot applications using Arconia CLI. Use when the user wants to containerize their application, build a Docker/OCI image, create a container image using Cloud Native Buildpacks or a Dockerfile/Containerfile, push an image to a registry, or build multi-architecture container images. Also use when the user mentions packaging for Kubernetes, deploying to a container platform, or creating production images.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

5.5 KB, as published. Nobody here has run it

Build Container Images for Spring Boot

Use arconia image build to package a Spring Boot application as a container image. Two strategies are available:

Strategy	Command	Dockerfile needed?
Buildpacks	`arconia image build buildpacks`	No
Dockerfile	`arconia image build dockerfile`	Yes

Both require an OCI container runtime (Podman or Docker) installed and running.

Buildpacks (recommended for most projects)

Cloud Native Buildpacks auto-detect the application type and produce an optimised image without a Dockerfile.

arconia image build buildpacks

With a custom image name:

arconia image build buildpacks --image-name ghcr.io/arconia-io/my-app:1.0.0

Buildpacks options

Option	Default	Description
`--image-name`		Image name and optional tag
`--builder-image`	(from Spring Boot plugin)	Buildpacks Builder image
`--run-image`	(from Builder)	Buildpacks Run image (base image of the produced container)
`--clean-cache`	`false`	Clean the Buildpacks local cache before building
`--publish-image`	`false`	Publish the image to an OCI registry after building
`--image-platform`		Target platform(s) (e.g., `linux/amd64`, `linux/arm64`)
`--clean`	`false`	Clean build the application before building the image
`--skip-tests`	`false`	Skip tests during the application build

Multi-architecture images

Specify multiple platforms to build a multi-arch OCI image index:

arconia image build buildpacks \
  --image-name ghcr.io/arconia-io/my-app:1.0.0 \
  --image-platform linux/amd64 \
  --image-platform linux/arm64 \
  --publish-image

Multi-arch builds require --publish-image because the OCI image index must be assembled from manifests already present in a registry.

Publish to a registry

Authenticate with the registry first, then use --publish-image:

podman login ghcr.io
arconia image build buildpacks \
  --image-name ghcr.io/arconia-io/my-app:1.0.0 \
  --publish-image

Dockerfile / Containerfile

Use this strategy when you need full control over the image build.

arconia image build dockerfile --image-name ghcr.io/arconia-io/my-app:1.0.0

The command looks for a Dockerfile/Containerfile in these locations (in order):

Containerfile (project root)
Dockerfile (project root)
src/main/podman/Containerfile
src/main/podman/Dockerfile
src/main/docker/Containerfile
src/main/docker/Dockerfile

Dockerfile options

Option	Default	Description
`--image-name` or `-t`	(required)	Image name and optional tag
`--dockerfile`, `--containerfile`, or `-f`	(auto-detected)	Path to the Dockerfile/Containerfile
`--oci-runtime`	(auto-detected: Podman then Docker)	OCI runtime to use (`docker` or `podman`)

Example multi-stage Dockerfile

FROM docker.io/library/eclipse-temurin:25-noble AS builder
WORKDIR /builder
# Adjust to 'target/*.jar' for Maven
ARG JAR_FILE=build/libs/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=tools -jar application.jar extract --layers --destination extracted

FROM docker.io/library/eclipse-temurin:25-jre-noble
RUN useradd spring
USER spring
WORKDIR /application
COPY --from=builder /builder/extracted/dependencies/ ./
COPY --from=builder /builder/extracted/spring-boot-loader/ ./
COPY --from=builder /builder/extracted/snapshot-dependencies/ ./
COPY --from=builder /builder/extracted/application/ ./
ENTRYPOINT ["java", "-jar", "application.jar"]

Pass extra arguments to the build tool

Use -- to forward arguments to the underlying Maven or Gradle command:

arconia image build buildpacks -- --stacktrace
arconia image build buildpacks -- -DmyProperty=value

Workflow

Build and test the application: arconia build && arconia test
Build the image: arconia image build buildpacks (or dockerfile)
Verify locally: podman run --rm -p 8080:8080 <image-name>
Publish: add --publish-image (buildpacks) or push manually (dockerfile)

Gotchas

An OCI container runtime (Podman or Docker) must be installed and running. The CLI prefers Podman and falls back to Docker.
arconia image build buildpacks does not require --image-name — it defaults to the Spring Boot plugin configuration. arconia image build dockerfile requires --image-name.
Multi-arch builds with multiple --image-platform values require --publish-image because the manifest list must be assembled in a registry.
To push images, authenticate with the registry first (e.g., podman login ghcr.io).
All commands support --verbose (-v) for detailed output when debugging build issues.
The -- separator is required to distinguish Arconia CLI flags from build tool arguments. Everything after -- is passed directly to Maven or Gradle.