Feature/readme javadocs ci

[jurgenei]

Add spotbugs and other checks

[qodo-code-review]

Review Summary by Qodo

Add conformance badges and improve error handling

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Add conformance badge to README documentation
• Improve directory creation error handling with validation
• Fix Gradle task input tracking for workDir property
• Enhance Python executable detection using environment variable

Diagram

flowchart LR
  A["PythonRunnerTask"] -->|"Add workDir path tracking"| B["@Input getWorkDirPath"]
  A -->|"Improve directory creation"| C["Error handling validation"]
  A -->|"Fix input annotation"| D["@Internal getWorkDir"]
  E["README"] -->|"Add badge"| F["Conformance status"]
  G["Test"] -->|"Improve detection"| H["Environment variable"]

Loading

File Changes

1. src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java Bug fix, enhancement +20/-5

Enhance error handling and Gradle task inputs

• Add @Internal annotation to getWorkDir() and create new @Input method getWorkDirPath() for
 proper Gradle task input tracking
• Improve directory creation with existence checks and throw GradleException on failure instead of
 silently failing
• Return defensive copy of args list in getArgs() method
• Add import for @Internal annotation

src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java

---

2. src/test/java/name/jurgenei/gradle/python/PythonRunnerTaskTest.java ✨ Enhancement +1/-1

Improve Python executable detection

• Replace hardcoded Python executable path check with environment variable lookup using
 System.getenv().getOrDefault()
• Improve cross-platform compatibility by allowing custom Python executable configuration

src/test/java/name/jurgenei/gradle/python/PythonRunnerTaskTest.java

---

3. README.md 📝 Documentation +2/-0

Add conformance status badge

• Add conformance badge indicating all checks are passing
• Badge placed prominently after main title

README.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

1. Args mutation ignored 🐞 Bug ≡ Correctness

Description

getArgs() now returns a defensive copy, so build scripts that do task.args.add(...) mutate only
the copy and the task still executes with the original internal args field, dropping expected CLI
arguments without any error. This is hard to diagnose because runScript() reads the internal field
directly, not the getter result.

Code

src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[R269-273]

Evidence

The task execution uses the internal args field (cmd.addAll(args)), but the @Input getter
returns a new list instance each call, so mutations via the getter are disconnected from what is
executed.

src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[122-127]
src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[264-273]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`getArgs()` returns a new `ArrayList` every call. In Gradle/Groovy DSL, users commonly configure list properties via mutation (e.g., `PythonRunnerTask { args.add('foo') }`). With the current implementation, those mutations do not affect the task’s internal `args` field that `runScript()` uses, so the script runs without the intended arguments.

### Issue Context
The task executes with `cmd.addAll(args)` (field), while the getter returns a copy. This creates a silent configuration no-op.

### Fix Focus Areas
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[41-45]
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[122-127]
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[264-282]

### Suggested fix approaches
Pick one:
1) **Gradle-native properties (best):** migrate `args` to a `ListProperty<String>` and use it consistently (execution reads from the property). This supports safe configuration (`args.add(...)`, `args.set(...)`) and proper input tracking.
2) **Minimal behavioral fix:** return the live list from `getArgs()` (so DSL mutations work) and, if SpotBugs complains, suppress that warning for this getter. Also consider making the field `final` and having `setArgs()` clear/add rather than reassigning the list.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Absolute workDir input 🐞 Bug ⚙ Maintainability

Description

getWorkDirPath() is marked as an @Input but returns workDir.getAbsolutePath(), which makes the
input value depend on the checkout location and can cause needless task invalidation between
different machines/paths. This also models the workDir only as a string rather than a directory
input with path sensitivity semantics.

Code

src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[R244-253]

Evidence

The new input method explicitly returns an absolute path string for “incremental input tracking,”
and the work directory is used as the process working directory and venv location, so
location-dependent inputs can cause unnecessary invalidations.

src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[79-94]
src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[244-253]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`getWorkDirPath()` uses an absolute path string for task input tracking, which varies by environment/checkout location and can reduce the usefulness of incremental tracking.

### Issue Context
The task uses the resolved work directory as the working directory and as the location for `.venv`.

### Fix Focus Areas
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[79-94]
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[234-253]

### Suggested fix
Prefer modeling this as a directory input:
- Annotate `getWorkDir()` as `@Optional @InputDirectory` and add `@PathSensitive(PathSensitivity.RELATIVE)` when appropriate (or another sensitivity that matches desired behavior).
- If you must keep a string input, consider using a normalized/project-relative path where feasible to avoid tying inputs to absolute checkout paths.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Args mutation ignored 🐞 Bug ≡ Correctness

getArgs() now returns a defensive copy, so build scripts that do task.args.add(...) mutate only
the copy and the task still executes with the original internal args field, dropping expected CLI
arguments without any error. This is hard to diagnose because runScript() reads the internal field
directly, not the getter result.

Agent Prompt

### Issue description
`getArgs()` returns a new `ArrayList` every call. In Gradle/Groovy DSL, users commonly configure list properties via mutation (e.g., `PythonRunnerTask { args.add('foo') }`). With the current implementation, those mutations do not affect the task’s internal `args` field that `runScript()` uses, so the script runs without the intended arguments.

### Issue Context
The task executes with `cmd.addAll(args)` (field), while the getter returns a copy. This creates a silent configuration no-op.

### Fix Focus Areas
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[41-45]
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[122-127]
- src/main/java/name/jurgenei/gradle/python/PythonRunnerTask.java[264-282]

### Suggested fix approaches
Pick one:
1) **Gradle-native properties (best):** migrate `args` to a `ListProperty<String>` and use it consistently (execution reads from the property). This supports safe configuration (`args.add(...)`, `args.set(...)`) and proper input tracking.
2) **Minimal behavioral fix:** return the live list from `getArgs()` (so DSL mutations work) and, if SpotBugs complains, suppress that warning for this getter. Also consider making the field `final` and having `setArgs()` clear/add rather than reassigning the list.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools