Canonicalize central CI caller shape#3
Conversation
📝 WalkthroughWalkthroughThe PR modernizes both CI infrastructure and test dependencies. A Maven CI workflow previously using inline steps now delegates to a reusable external workflow, and test-scoped Mockito and Byte Buddy dependencies are updated to newer versions for improved compatibility and functionality. ChangesCI and Test Dependencies Modernization
Estimated Code Review Effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly Related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
pom.xml (1)
89-94: 💤 Low value
mockito-inlineis redundant on Mockito 5.x and can be dropped.Since Mockito Inline became the default mock maker since Mockito Core version 5.0.0, the inline mock maker is already built into
mockito-core:5.2.0. The separatemockito-inlineartifact adds nothing here, and it was later removed from Mockito entirely, so keeping it invites confusion on future upgrades.♻️ Proposed cleanup
- <dependency> - <groupId>org.mockito</groupId> - <artifactId>mockito-inline</artifactId> - <version>5.2.0</version> - <scope>test</scope> - </dependency>🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pom.xml` around lines 89 - 94, Remove the redundant mockito-inline dependency declaration (artifactId: mockito-inline) from the pom.xml; Mockito Core 5.x already includes the inline mock maker so delete the <dependency> block for mockito-inline and keep/ensure the project uses the existing mockito-core:5.2.0 test-scoped dependency instead..github/workflows/maven-ci.yml (2)
11-11: 💤 Low valueUnpinned reusable-workflow reference (zizmor blanket policy).
zizmor flags
@v1as not pinned to a commit SHA. The inline comment documents an intentional choice to track the floating major tag for auto re-pins, which is a reasonable supply-chain tradeoff — but it does conflict with a strict "pin to hash" policy. If the policy is enforced in CI, this will keep failing; consider pinning to an immutable SHA (optionally with a Dependabot/Renovate rule) or explicitly allow-listing trusted first-partyUltiKits/*workflows in the zizmor config.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/maven-ci.yml at line 11, The reusable workflow reference is using a floating tag "UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1" which violates the strict pin-to-SHA policy; update that "uses:" entry to reference the exact immutable commit SHA for the UltiKits workflow (or add an explicit allow-list entry for UltiKits/* in the zizmor config) so CI/policy checks pass—locate the "uses: UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1" line and replace the tag with the corresponding commit SHA (or adjust zizmor allow-list) and document the change.
9-13: 🏗️ Heavy liftConfirm delegated reusable-workflow inputs/JDK match the current Maven/Mockito requirements.
- The reusable workflow
UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1definesworkflow_callinputneeds-nmsas a boolean (defaultfalse), soneeds-nms: falseis valid.- With
needs-nms: false, it runs the non-NMS test matrix on JDK17and21(and21whenneeds-nms: true), so the Java 11+ runtime requirement for Mockito5.2.0is satisfied.zizmor’sunpinned-useswarning foruses: ...@v1remains a policy decision; pinning to a commit SHA would silence it if required.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/maven-ci.yml around lines 9 - 13, Verify the delegated reusable workflow inputs and JDKs: confirm the called workflow's workflow_call input needs-nms is a boolean with default false (matches current uses: UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1), and that with needs-nms: false the test matrix targets JDK 17 and 21 (ensuring Mockito 5.2.0’s Java 11+ requirement is met); if policy requires stricter pinning, replace uses: ...@v1 with a specific commit SHA to silence the unpinned-uses warning.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pom.xml`:
- Around line 78-94: Mockito 5.2.0 (dependencies mockito-core,
mockito-junit-jupiter, mockito-inline) requires a Java 11+ test runtime even if
compilation target is 1.8; update the project/CI to run tests on JDK >=11 by
changing the project java runtime configuration (e.g., update <java.version>
from 1.8 to 11 or configure Maven toolchains/surefire/failsafe to use Java 11+)
and adjust the reusable workflow referenced by maven-ci.yml so the test job runs
on JDK 11+ (do not remove mockito-inline since mockStatic usage depends on it).
---
Nitpick comments:
In @.github/workflows/maven-ci.yml:
- Line 11: The reusable workflow reference is using a floating tag
"UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1" which violates the
strict pin-to-SHA policy; update that "uses:" entry to reference the exact
immutable commit SHA for the UltiKits workflow (or add an explicit allow-list
entry for UltiKits/* in the zizmor config) so CI/policy checks pass—locate the
"uses: UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1" line and replace
the tag with the corresponding commit SHA (or adjust zizmor allow-list) and
document the change.
- Around line 9-13: Verify the delegated reusable workflow inputs and JDKs:
confirm the called workflow's workflow_call input needs-nms is a boolean with
default false (matches current uses:
UltiKits/ci-workflows/.github/workflows/maven-ci.yml@v1), and that with
needs-nms: false the test matrix targets JDK 17 and 21 (ensuring Mockito 5.2.0’s
Java 11+ requirement is met); if policy requires stricter pinning, replace uses:
...@v1 with a specific commit SHA to silence the unpinned-uses warning.
In `@pom.xml`:
- Around line 89-94: Remove the redundant mockito-inline dependency declaration
(artifactId: mockito-inline) from the pom.xml; Mockito Core 5.x already includes
the inline mock maker so delete the <dependency> block for mockito-inline and
keep/ensure the project uses the existing mockito-core:5.2.0 test-scoped
dependency instead.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 57ea303d-6fb4-47cc-8a9b-57d9541baa95
📒 Files selected for processing (2)
.github/workflows/maven-ci.ymlpom.xml
| <groupId>org.mockito</groupId> | ||
| <artifactId>mockito-core</artifactId> | ||
| <version>4.11.0</version> | ||
| <version>5.2.0</version> | ||
| <scope>test</scope> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.mockito</groupId> | ||
| <artifactId>mockito-junit-jupiter</artifactId> | ||
| <version>4.11.0</version> | ||
| <version>5.2.0</version> | ||
| <scope>test</scope> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.mockito</groupId> | ||
| <artifactId>mockito-inline</artifactId> | ||
| <version>4.11.0</version> | ||
| <version>5.2.0</version> | ||
| <scope>test</scope> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does Mockito 5.2.0 support running tests on JDK 21, or is a newer Mockito 5.x release recommended?
💡 Result:
Mockito 5.2.0 can run tests on JDK 21, but you may need to ensure the correct Byte Buddy dependency is resolved; otherwise you can hit JDK-21-related Byte Buddy issues with mockito-inline 5.2.0.[1][2] Recommendation: use a newer Mockito 5.x (e.g., the latest 5.x) for best JDK-21 compatibility and fixes. Mockito explicitly documents JDK 21+ instrumentation behavior (Java 21 restricts agent attachment) and provides guidance to configure Mockito as a Java agent when running tests on Java 21+.[3] Mockito 5.x also continues to add JDK 21-related support over time (e.g., “Support for JDK21 Sequenced Collections” in releases around 5.19+).[4] In short: 5.2.0 is not guaranteed to be the smoothest experience on JDK 21; for reliability on JDK 21, prefer a more recent Mockito 5.x and follow the Java 21+ agent setup guidance.[3]
Citations:
- 1: https://groups.google.com/g/mockito/c/psRyztIa5mY
- 2: https://central.sonatype.com/artifact/org.mockito/mockito-core/5.2.0
- 3: https://github.com/mockito/mockito/blob/main/mockito-core/src/main/java/org/mockito/Mockito.java
- 4: https://github.com/mockito/mockito/releases
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show relevant portions of pom.xml
echo "=== pom.xml (java.version + compiler/surefire) ==="
sed -n '1,140p' pom.xml | nl -ba | sed -n '1,140p'
echo
echo "=== pom.xml (dependencies around Mockito/byte-buddy) ==="
nl -ba pom.xml | sed -n '60,140p'
echo
echo "=== Search for mockito inline / mock maker extension files ==="
rg -n --hidden --no-ignore-vcs "mockito-inline|MockMaker|mockito-extensions|org\.mockito\.plugins\.MockMaker" .Repository: UltiKits/UltiBackup
Length of output: 175
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Print pom.xml top section with line numbers
echo "=== pom.xml (top: java.version / properties) ==="
sed -n '1,120p' pom.xml | cat -n
echo
echo "=== pom.xml (Mockito/byte-buddy dependencies around 60-140) ==="
sed -n '60,160p' pom.xml | cat -n
echo
echo "=== Search for Mockito mock-maker configuration files/usages ==="
rg -n --hidden --no-ignore-vcs "mockito-inline|MockMaker|mockito-extensions|org\.mockito\.plugins\.MockMaker" .
echo
rg -n --hidden --no-ignore-vcs "byte-buddy|byte-buddy-agent" pom.xmlRepository: UltiKits/UltiBackup
Length of output: 9841
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== CI workflows: look for setup-java / Java version ==="
ls -la .github 2>/dev/null || true
ls -la .github/workflows 2>/dev/null || true
rg -n "setup-java|JAVA_VERSION|java-version|temurin|adoptopenjdk|jdk" .github/workflows .github 2>/dev/null || true
echo
echo "=== Any other CI config (e.g., Jenkins) mentioning Java version? ==="
rg -n "JDK|JAVA_HOME|sourceCompatibility|maven.*java|setup-java|temurin|adoptopenjdk|java" . 2>/dev/null | head -n 50Repository: UltiKits/UltiBackup
Length of output: 6028
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== .github/workflows/maven-ci.yml ==="
sed -n '1,220p' .github/workflows/maven-ci.yml | cat -n
echo
echo "=== Search for Mockito static mocking / inline-only APIs ==="
rg -n "mockStatic\(|MockedStatic|mockito\\.inline|inline mock|`@Mock`|`@InjectMocks`" src/test/java -S || true
echo
echo "=== Search for mockito-extensions directory/files ==="
fd "mockito-extensions" . -t f 2>/dev/null || true
rg -n --hidden --no-ignore-vcs "org\.mockito\.plugins\.MockMaker|mockito-extensions" . || true
echo
echo "=== Search for explicit final/static mocking hints ==="
rg -n "when\\(|thenReturn\\(|final class|final .*\\{|static .*\\{" src/test/java -S || trueRepository: UltiKits/UltiBackup
Length of output: 50375
🌐 Web query:
What is the minimum supported Java version for Mockito 5.x (specifically 5.2.0)? Mockito 5 Java 11+ requirement
💡 Result:
The minimum supported Java version for all versions of Mockito 5.x, including 5.2.0, is Java 11 [1][2][3]. Mockito increased its minimum Java requirement from Java 8 to Java 11 starting with the release of version 5.0.0 [1][4]. This change was implemented to reduce maintenance costs, manage infrastructure complexities, and accommodate evolving JDK APIs (such as the SecurityManager) [1][5]. Users who require support for Java 8 or earlier versions are advised to continue using Mockito 4 [1][3].
Citations:
- 1: https://github.com/mockito/mockito/releases/tag/v5.0.0
- 2: https://github.com/mockito/mockito/blob/main/README.md
- 3: https://davidvlijmincx.com/posts/upgrade-to-mockito-5/
- 4: https://www.infoq.com/news/2023/01/mockito-5/
- 5: https://github.com/mockito/mockito/wiki/Draft-Mockito-5-release-notes
🌐 Web query:
Does Mockito static mocking (MockedStatic / mockStatic) require mockito-inline (inline mock maker) even when mockito-core is present?
💡 Result:
No, not necessarily. 1) If you are on Mockito 5.0.0+ (and your setup uses the inline MockMaker by default), then static mocking via mockStatic/MockedStatic does not require adding the mockito-inline artifact explicitly, because the default mock maker is the inline one that supports static mocks.[1][2] 2) If you are on an older Mockito version, or if your configuration is using the subclass MockMaker (e.g., you have only mockito-core with a MockMaker that “does not support the creation of static mocks”), then you must enable the inline mock maker. Mockito’s guidance is to “enable this mock mode, by placing the 'mockito-inline' artifact where you are currently using 'mockito-core'” and to use the inline mock maker to support static mocking.[3][4] Practical takeaway: whether mockito-inline is required depends on which MockMaker is active in your test runtime. For Mockito 5+, it’s typically not required because inline is the default; for Mockito 3/4 or a subclass MockMaker configuration, it is required for mockStatic to work.[3][1][4]
Citations:
- 1: https://javadoc.io/static/org.mockito/mockito-core/5.23.0/org.mockito/org/mockito/Mockito.html
- 2: https://github.com/mockito/mockito
- 3: https://javadoc.io/static/org.mockito/mockito-core/4.6.1/org/mockito/Mockito.html
- 4: https://stackoverflow.com/questions/70240898/mockito-cannot-mock-a-static-method
🌐 Web query:
UltiKits/ci-workflows maven-ci.yml: what Java version does it run tests with? (setup-java java-version)
💡 Result:
The repository UltiKits/ci-workflows does not appear to exist as a public GitHub repository. Consequently, there is no authoritative maven-ci.yml file associated with this path to provide a specific Java version. Development and CI for UltiKits projects (such as UltiTools-Reborn) are primarily managed via the UltiTools CLI [1][2], which scaffolds Maven projects locally [2]. Users looking for Java CI templates for Maven projects typically use the standard GitHub Actions "Java with Maven" template [3][4][5], which commonly defaults to Java 17 [4][6][7].
Citations:
- 1: https://github.com/UltiKits/UltiTools-Reborn
- 2: UltiKits/UltiTools-Dev-Doc@43bd86b
- 3: https://docs.github.com/actions/guides/building-and-testing-java-with-maven
- 4: https://github.com/actions/starter-workflows/blob/main/ci/maven.yml
- 5: https://help.github.com/en/actions/language-and-framework-guides/building-and-testing-java-with-maven
- 6: https://github.com/github/docs/blob/main/content/actions/tutorials/build-and-test-code/java-with-maven.md
- 7: https://github.com/github/docs/blob/main/content/actions/tutorials/build-and-test-code/java-with-gradle.md
Mockito 5.2.0 requires a Java 11+ test runtime (not just compilation to 1.8)
<java.version>1.8</java.version> (line 16) only sets the compiler source/target; Mockito 5.2.0 needs Java 11+ to run tests, so mvn test on a JDK 8 JVM will fail with class-version/runtime errors. Ensure both local dev and the test CI job execute with JDK >= 11 (maven-ci.yml delegates to a reusable workflow, so that workflow’s JDK needs to be checked/adjusted).
mockito-inline:5.2.0 is not redundant: the test suite uses org.mockito.MockedStatic / mockStatic(...), which relies on inline mocking being available.
Optional: targeting JDK 21—Mockito 5.2.0 can work, but upgrading to a newer Mockito 5.x release can reduce Byte Buddy/JDK21 edge-case friction.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pom.xml` around lines 78 - 94, Mockito 5.2.0 (dependencies mockito-core,
mockito-junit-jupiter, mockito-inline) requires a Java 11+ test runtime even if
compilation target is 1.8; update the project/CI to run tests on JDK >=11 by
changing the project java runtime configuration (e.g., update <java.version>
from 1.8 to 11 or configure Maven toolchains/surefire/failsafe to use Java 11+)
and adjust the reusable workflow referenced by maven-ci.yml so the test job runs
on JDK 11+ (do not remove mockito-inline since mockStatic usage depends on it).
Phase 17-04 Gate B1/B2 evidence PR.
ci-workflows@v1reusable Maven CI caller.needs-nms: false..github/workflows/maven-ci.yml.Summary by CodeRabbit