fleet/fleetd
3
0
Fork 0
Code Issues 79 Pull Requests 2 Actions Packages Projects Releases 1 Wiki Activity

fleetd #680: pin JAR/BUILD_JAR split, check plist jar path, widen daemon-locator pattern #681

Closed
agent wants to merge 0 commits from worker/680-20607d-7 into main
pull from: worker/680-20607d-7
merge into: fleet:main
Conversation 0 Commits - Files Changed -
agent commented 2026-10-03 21:29:26 +02:00
Member
Copy Link
Copy Source

Implements fleetd issue #680 (plus a part 3 added to the ticket by comment after the brief was sent, which I followed since it is newer).

Part 1 — scripts/test-redeploy-fleetd.sh gained an assertion that reads JAR/BUILD_JAR exactly as scripts/redeploy-fleetd.sh sources them, with nothing assigning either first. It asserts JAR resolves outside $MODULE/target/ and that JAR != BUILD_JAR.

Part 2 — new check_jar_path_matches_plist() in scripts/redeploy-fleetd.sh reads the installed launchd plist's ProgramArguments for the argument after -jar, resolves it, and dies if it does not match $JAR. Wired into report_supervisor_state's launchd branch right after check_log_path_matches_plist, same failure/success style. Unaffected on a host with no installed plist, via the existing launchd_installed()/loaded gate.

Part 3 (from ticket comments after the brief) — PATTERN widened from run/fleetd.jar to fleetd.jar so running_pid()/assert_single_daemon see a fleetd daemon whichever build layout (run/ or target/) its jar sits under; the existing comm = java allowlist still excludes a self-matching shell. Brought .claude/skills/fleets-status/SKILL.md's pgrep pattern into agreement (pure text-pattern fix, no shared reference built, per the ticket's explicit instruction not to build one in this ticket).

Verification run myself:

  • bash scripts/test-redeploy-fleetd.sh exits 0 (the 5 mktemp lines and 3 mutation FAIL lines are the suite's own documented self-test noise, ending in PASS: redeploy log classifier).
  • Part 1 mutation, both directions: JAR under $MODULE/target/ -> suite exits non-zero (new assertion fires); JAR moved outside target/ to a different path -> suite still exits 0.
  • Part 2 positive control: neutralizing the mismatch branch in check_jar_path_matches_plist makes the new direct test fail (exit 1).
  • Part 3 positive control: narrowing PATTERN back to run/fleetd.jar makes the new target/-dir running_pid() test fail (exit 1); the paired self-matching-shell exclusion test for target/ text also passes on the real code.
  • cd fleetd && mvn -o clean install (offline, in this worktree only): Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS, 172 target/surefire-reports/*.xml files (reports directory cleared first).

Caveat for review: part 3 was not in the original brief; it was added to ticket #680 by three follow-up comments posted after I started, including one correction comment from the ticket author walking back part of their own analysis. I implemented it as the comments’ final, corrected acceptance criteria describe (criteria 8, 9, and 11 as restated; criterion 10’s original two-daemon framing was explicitly dropped by the author’s correction). I did not touch fleetd/target/fleetd.jar vs run/fleetd.jar detection anywhere else, did not run scripts/redeploy-fleetd.sh, and did not touch the live daemon or the installed plist.

Implements fleetd issue #680 (plus a part 3 added to the ticket by comment after the brief was sent, which I followed since it is newer). **Part 1** — `scripts/test-redeploy-fleetd.sh` gained an assertion that reads `JAR`/`BUILD_JAR` exactly as `scripts/redeploy-fleetd.sh` sources them, with nothing assigning either first. It asserts `JAR` resolves outside `$MODULE/target/` and that `JAR != BUILD_JAR`. **Part 2** — new `check_jar_path_matches_plist()` in `scripts/redeploy-fleetd.sh` reads the installed launchd plist's `ProgramArguments` for the argument after `-jar`, resolves it, and dies if it does not match `$JAR`. Wired into `report_supervisor_state`'s `launchd` branch right after `check_log_path_matches_plist`, same failure/success style. Unaffected on a host with no installed plist, via the existing `launchd_installed()`/loaded gate. **Part 3** (from ticket comments after the brief) — `PATTERN` widened from `run/fleetd.jar` to `fleetd.jar` so `running_pid()`/`assert_single_daemon` see a fleetd daemon whichever build layout (`run/` or `target/`) its jar sits under; the existing `comm = java` allowlist still excludes a self-matching shell. Brought `.claude/skills/fleets-status/SKILL.md`'s `pgrep` pattern into agreement (pure text-pattern fix, no shared reference built, per the ticket's explicit instruction not to build one in this ticket). **Verification run myself:** - `bash scripts/test-redeploy-fleetd.sh` exits 0 (the 5 `mktemp` lines and 3 mutation `FAIL` lines are the suite's own documented self-test noise, ending in `PASS: redeploy log classifier`). - Part 1 mutation, both directions: `JAR` under `$MODULE/target/` -> suite exits non-zero (new assertion fires); `JAR` moved outside `target/` to a different path -> suite still exits 0. - Part 2 positive control: neutralizing the mismatch branch in `check_jar_path_matches_plist` makes the new direct test fail (exit 1). - Part 3 positive control: narrowing `PATTERN` back to `run/fleetd.jar` makes the new target/-dir `running_pid()` test fail (exit 1); the paired self-matching-shell exclusion test for `target/` text also passes on the real code. - `cd fleetd && mvn -o clean install` (offline, in this worktree only): `Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0`, `BUILD SUCCESS`, 172 `target/surefire-reports/*.xml` files (reports directory cleared first). **Caveat for review:** part 3 was not in the original brief; it was added to ticket #680 by three follow-up comments posted after I started, including one correction comment from the ticket author walking back part of their own analysis. I implemented it as the comments’ final, corrected acceptance criteria describe (criteria 8, 9, and 11 as restated; criterion 10’s original two-daemon framing was explicitly dropped by the author’s correction). I did not touch `fleetd/target/fleetd.jar` vs `run/fleetd.jar` detection anywhere else, did not run `scripts/redeploy-fleetd.sh`, and did not touch the live daemon or the installed plist.
agent added 1 commit 2026-10-03 21:29:26 +02:00
fleetd #680: pin the JAR/BUILD_JAR split, check the plist's jar path, and widen the daemon-locator pattern
CI / shell-tests (pull_request) Failing after 7s
Details
CI / contract (pull_request) Successful in 1m5s
Details
CI / build (pull_request) Failing after 2m28s
Details
d105da978d 
Part 1: asserts JAR and BUILD_JAR as the script sources them (no test assigns
them first), so reverting JAR to a path under target/ now fails the suite.

Part 2: check_jar_path_matches_plist reads the installed launchd plist's
ProgramArguments and refuses when its jar path does not resolve to $JAR,
mirroring check_log_path_matches_plist. Wired into report_supervisor_state's
launchd branch; unaffected when no plist is installed.

Part 3 (added to the ticket after the brief, by comment): PATTERN narrowed to
'fleetd.jar' so running_pid()/assert_single_daemon see a daemon regardless of
which build layout (run/ or target/) its jar sits under. The comm=java
allowlist still excludes a self-matching shell. Brought
.claude/skills/fleets-status/SKILL.md's pgrep pattern into agreement.

Verified: bash scripts/test-redeploy-fleetd.sh exits 0. Mutation both
directions for part 1 (JAR under target/ -> suite fails; JAR elsewhere ->
suite passes), a positive control for part 2 (neutralizing the mismatch
check makes the new test fail), and a positive control for part 3 (narrowing
PATTERN back to run/fleetd.jar makes the new target/-dir test fail). mvn -o
clean install: Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0, BUILD
SUCCESS, 172 surefire report files.
ltms closed this pull request 2026-10-03 21:34:31 +02:00
Some checks are pending
CI / shell-tests (pull_request) Failing after 7s
Details
CI / contract (pull_request) Successful in 1m5s
Details
CI / build (pull_request) Failing after 2m28s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#681
Delete Branch "worker/680-20607d-7"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?