Skip to content

Use JavaFX-enabled JDK for builds#7

Closed
Mika3578 wants to merge 3 commits intonew-repofrom
codex/add-complete-pipeline-workflow-for-build
Closed

Use JavaFX-enabled JDK for builds#7
Mika3578 wants to merge 3 commits intonew-repofrom
codex/add-complete-pipeline-workflow-for-build

Conversation

@Mika3578
Copy link
Owner

@Mika3578 Mika3578 commented Nov 23, 2025

Summary

  • configure CI and CodeQL workflows to install a JavaFX-enabled JDK via Zulu
  • update Docker build and runtime images to Liberica variants that include JavaFX support

Testing

  • not run (not requested)

Codex Task

Summary by Sourcery

Set up JavaFX-compatible build, analysis, and containerization pipelines for the project.

Build:

  • Add Maven-based CI workflow using a JavaFX-enabled Zulu JDK across major OS targets.
  • Introduce a multi-stage Docker build using Liberica images with JavaFX support for building and running the application.

CI:

  • Add GitHub Actions CI workflow to build and test the project on push and pull requests.
  • Add GitHub Actions CodeQL workflow configured with a JavaFX-enabled JDK for scheduled and PR-based code scanning.

Deployment:

  • Define a Dockerfile to produce a runnable container image for the application using a JavaFX-capable runtime base image.

Chores:

  • Add Dependabot configuration to automatically track updates for GitHub Actions, Maven, and Docker dependencies.
  • Add placeholder configuration files for Docker ignore rules and Renovate dependency management.

@sourcery-ai
Copy link

sourcery-ai bot commented Nov 23, 2025

Reviewer's Guide

Configures CI and CodeQL workflows to build and analyze the project with a JavaFX-enabled JDK 17, introduces a two-stage Docker build and runtime image based on Liberica images with JavaFX support, and sets up automated dependency update configuration for GitHub Actions, Maven, and Docker images.

Sequence diagram for CI and Docker build workflows using JavaFX-enabled JDK

sequenceDiagram
    actor "Developer" as Dev
    participant "GitHub" as GH
    participant "CI Workflow (ci.yml)" as CI
    participant "Build Job (matrix ubuntu/windows/macos)" as BuildJob
    participant "setup-java (Zulu JDK 17 + JavaFX)" as SetupJava
    participant "Maven Wrapper (./mvnw verify)" as Maven
    participant "Docker Build Job" as DockerJob
    participant "docker/setup-buildx-action" as Buildx
    participant "docker/build-push-action" as BuildPush

    Dev->>GH: "Push or open pull request"
    GH->>CI: "Trigger CI workflow on push/pull_request"

    CI->>BuildJob: "Start matrix build on each OS"
    BuildJob->>SetupJava: "Install 'Zulu JDK 17' with 'jdk+fx' and cache 'maven'"
    SetupJava-->>BuildJob: "JDK 17 with JavaFX configured"
    BuildJob->>Maven: "Run './mvnw -B -ntp verify'"
    Maven-->>BuildJob: "Build and tests completed"
    BuildJob-->>CI: "Build job success or failure"

    CI->>DockerJob: "Start Docker image build (needs: build) on success"
    DockerJob->>Buildx: "Set up Buildx builder"
    Buildx-->>DockerJob: "Buildx configured"
    DockerJob->>BuildPush: "Build image with context '.' and file './Dockerfile' (push: false)"
    BuildPush-->>DockerJob: "Docker image built locally"
    DockerJob-->>CI: "Docker build job completed"
    CI-->>GH: "Report CI status on commit/PR"
Loading

Flow diagram for multi-stage Docker build with Liberica JavaFX images

flowchart TD
    SRC["Source Code (including Maven Wrapper)"]

    subgraph "Build Stage"
        BaseBuild["FROM bellsoft/liberica-openjdk-debian:17"]
        WorkdirBuild["WORKDIR /workspace"]
        CopySrc["COPY . ."]
        MavenPackage["RUN ./mvnw -B -ntp package -DskipTests"]
        JarBuilt["Output: /workspace/application/habiTv/target/habiTv-*.jar"]
    end

    subgraph "Runtime Stage"
        BaseRuntime["FROM bellsoft/liberica-openjre-full-debian:17"]
        WorkdirRuntime["WORKDIR /opt/habitv"]
        CopyJar["COPY --from=build habiTv-*.jar to app.jar"]
        EntryPoint["ENTRYPOINT ['java', '-jar', '/opt/habitv/app.jar']"]
    end

    SRC --> BaseBuild
    BaseBuild --> WorkdirBuild
    WorkdirBuild --> CopySrc
    CopySrc --> MavenPackage
    MavenPackage --> JarBuilt

    JarBuilt --> BaseRuntime
    BaseRuntime --> WorkdirRuntime
    WorkdirRuntime --> CopyJar
    CopyJar --> EntryPoint
Loading

File-Level Changes

Change Details Files
Add CI workflow to build and test on multiple OSes using a JavaFX-enabled JDK and build a Docker image.
  • Introduce a GitHub Actions workflow that runs Maven verify on Ubuntu, Windows, and macOS using Zulu JDK 17 with JavaFX enabled and Maven dependency caching.
  • Add a dependent Docker build job that uses docker/setup-buildx-action and docker/build-push-action to build the application container image without pushing it.
.github/workflows/ci.yml
Add CodeQL security analysis workflow using a JavaFX-enabled JDK.
  • Create a GitHub Actions workflow that runs CodeQL analysis for Java on pushes, pull requests, and a weekly cron schedule.
  • Configure the workflow to use Zulu JDK 17 with JavaFX and Maven caching before running CodeQL init, autobuild, and analyze steps.
.github/workflows/codeql.yml
Introduce a multi-stage Docker build using Liberica images with JavaFX support for both build and runtime.
  • Add a build stage based on bellsoft/liberica-openjdk-debian:17 that copies the project source and runs the Maven wrapper to build a package with tests skipped.
  • Add a runtime stage based on bellsoft/liberica-openjre-full-debian:17 that copies the built JAR from the build stage into /opt/habitv and sets a java -jar entrypoint to run the application.
Dockerfile
Set up automated dependency update tooling for GitHub Actions, Maven, and Docker artifacts.
  • Configure Dependabot to check weekly for updates to GitHub Actions, Maven dependencies, and Docker dependencies in the repository.
  • Introduce Renovate configuration file placeholder for future automated dependency management rules.
  • Add a .dockerignore file placeholder to control Docker build context (contents not shown in diff).
.github/dependabot.yml
renovate.json
.dockerignore

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey there - I've reviewed your changes - here's some feedback:

  • The .dockerignore file is currently empty, so you may want to add common exclusions (e.g., target/, .git/, .github/, local IDE files) to reduce Docker build context size and improve build performance.
  • There is an empty renovate.json alongside .github/dependabot.yml; consider either populating renovate.json with the intended configuration or removing it to avoid confusion about which dependency update tool is in use.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The `.dockerignore` file is currently empty, so you may want to add common exclusions (e.g., `target/`, `.git/`, `.github/`, local IDE files) to reduce Docker build context size and improve build performance.
- There is an empty `renovate.json` alongside `.github/dependabot.yml`; consider either populating `renovate.json` with the intended configuration or removing it to avoid confusion about which dependency update tool is in use.

## Individual Comments

### Comment 1
<location> `.github/workflows/ci.yml:30-31` </location>
<code_context>
+          cache: maven
+          java-package: jdk+fx
+
+      - name: Build and test
+        run: ./mvnw -B -ntp verify
+
+  docker-build:
</code_context>

<issue_to_address>
**suggestion:** Consider handling Windows runners explicitly for the Maven wrapper invocation.

On `windows-latest`, PowerShell is the default shell, so `./mvnw` can be unreliable (execution policy, line endings, missing execute bit, etc.). To avoid flaky Windows jobs, either run this step with `shell: bash` so `./mvnw` behaves consistently across OSes, or use a matrix conditional to run `mvnw.cmd` on Windows and `./mvnw` elsewhere.

```suggestion
      - name: Build and test
        shell: bash
        run: ./mvnw -B -ntp verify
```
</issue_to_address>

### Comment 2
<location> `Dockerfile:8-11` </location>
<code_context>
+RUN ./mvnw -B -ntp package -DskipTests
+
+# Runtime stage
+FROM bellsoft/liberica-openjre-full-debian:17
+WORKDIR /opt/habitv
+COPY --from=build /workspace/application/habiTv/target/habiTv-*.jar app.jar
+ENTRYPOINT ["java", "-jar", "/opt/habitv/app.jar"]
</code_context>

<issue_to_address>
**🚨 suggestion (security):** Run the container as a non-root user to improve security.

The image currently runs as root, which unnecessarily amplifies the impact of a compromise. Please add a dedicated non-root user in the final stage, ensure the working directory/JAR are owned by that user, and set USER before ENTRYPOINT. This aligns with standard best practices and common container security scanner requirements.
</issue_to_address>

### Comment 3
<location> `Dockerfile:4` </location>
<code_context>
+# Build stage
+FROM bellsoft/liberica-openjdk-debian:17 AS build
+WORKDIR /workspace
+COPY . .
+RUN ./mvnw -B -ntp package -DskipTests
+
</code_context>

<issue_to_address>
**suggestion (performance):** Limit the Docker build context (and COPY) to reduce image build time and noise.

`COPY . .` brings the entire context into the image (including `.git`, build artifacts, IDE files, etc.), which slows builds and bloats layers. Since `.dockerignore` is empty, either add common exclusions (e.g., `.git`, `**/target`, `**/node_modules`, IDE configs) or change `COPY` to only include what Maven needs (e.g., `pom.xml` and module directories) to keep images lean and builds faster, especially in CI.

Suggested implementation:

```
# Build stage
FROM bellsoft/liberica-openjdk-debian:17 AS build
WORKDIR /workspace

# Copy only what Maven needs instead of the entire build context
COPY mvnw ./
COPY .mvn .mvn
COPY pom.xml ./
COPY application/habiTv/pom.xml application/habiTv/pom.xml
COPY application/habiTv/src application/habiTv/src

RUN ./mvnw -B -ntp package -DskipTests

```

To fully implement your suggestion and keep the build context lean, you should also:
1) Add a `.dockerignore` file at the repo root that at least ignores:
   - `.git`
   - `**/target`
   - `**/node_modules`
   - `.idea`, `.vscode`, `.project`, `.classpath`, `.settings/`
   - `*.iml`
2) If there are additional Maven modules required to build `application/habiTv`, you must add corresponding `COPY` lines for their `pom.xml` and `src` directories, similar to the ones shown for `application/habiTv`.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +29 to +31

- name: Build and test
run: ./mvnw -B -ntp verify

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Use Windows-safe Maven wrapper in matrix build

The CI matrix includes windows-latest (line 17), but the shared build step runs ./mvnw -B -ntp verify (lines 30-31). On Windows runners the default shell is PowerShell, so ./mvnw executes the Unix wrapper instead of mvnw.cmd and the Windows leg fails before the build even starts. Switching the Windows leg to mvnw.cmd or forcing a Bash shell is needed to keep the matrix green.

Useful? React with 👍 / 👎.

Comment on lines +1 to +5
# Build stage
FROM bellsoft/liberica-openjdk-debian:17 AS build
WORKDIR /workspace
COPY . .
RUN ./mvnw -B -ntp package -DskipTests

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Build image uses JDK without JavaFX dependencies

The Docker build stage is based on bellsoft/liberica-openjdk-debian:17 (lines 1-2), which is the standard JDK without JavaFX, but the project modules compile directly against JavaFX classes provided by the JDK itself (e.g., application/trayView/pom.xml lines 12-47 contain no JavaFX dependencies). Building the container with this image will fail ./mvnw … package at compile time because javafx.* classes are missing, even though the runtime stage already uses the *-full JavaFX variant. Use a JavaFX-enabled JDK image (e.g., Liberica full) for the build stage to make the Docker build succeed.

Useful? React with 👍 / 👎.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix

Mika3578 and others added 2 commits November 23, 2025 23:25
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
@Mika3578 Mika3578 closed this Nov 24, 2025
@Mika3578 Mika3578 deleted the codex/add-complete-pipeline-workflow-for-build branch November 24, 2025 23:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant