Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(deploy): in-container build Dockerfiles — build the image without a host JDK

Open
  • Is something wrong?
#674 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
docker, java
Domain
devops

Research direction

Start with the existing Dockerfile(s) at the repository root to see the current runtime stage layout, then check the README quickstart and the CI workflow that builds images. Add Dockerfile.jvm-build and Dockerfile.native-build as multi-stage files whose first stage builds the app with Maven and a JDK or Mandrel/GraalVM image, reusing a Maven cache mount. Done when both images build from a clean host with only Docker installed and CI builds them on release tags.

Written by the indexing model from the issue text.

Description

enhancement
Problem Statement

Building the container today requires a host toolchain (JDK 21+, Maven, and GraalVM for the native image) before docker build can run. For the self-hosting audience — the project's core audience — that's real onboarding friction: "install Java to build the Docker image" defeats part of the point of shipping a container.

Proposed Solution

Add multi-stage, in-container build Dockerfiles so docker build is the only prerequisite:

  • Dockerfile.jvm-build — stage 1 builds with a Maven+JDK image, stage 2 is the existing runtime layout.
  • Dockerfile.native-build — stage 1 builds the native image with a Mandrel/GraalVM builder image, stage 2 the existing micro base.
  • Layer-cache the Maven repository (--mount=type=cache) so rebuilds are fast.
  • Document both in the README quickstart as the zero-toolchain path; keep the current host-build Dockerfiles for CI/dev speed.
  • CI builds the in-container variants at least on release tags so they can't rot.

Pairs with #318 (try-before-self-host onboarding): both lower the "first successful deploy" bar.

Alternatives Considered
  • Publish pre-built images only — necessary but not sufficient; self-hosters patching or pinning forks still need a no-toolchain build path.
  • Devcontainer — helps contributors, not deployers.
Priority

Nice to have

Dominant language
Java
Stars
35
Forks
7
Avg merge
9h 23m
Merged PRs (30d)
154

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from devops-thiago/ThrillhouseBot

All issues in devops-thiago/ThrillhouseBot

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.