DI fix passes locally in grunt-runner Docker but still fails on actual Forgejo runner. Adding diagnostic tests to isolate whether mock() tracking itself is broken, or something else in the runner environment causes it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
6.1 KiB
PRD #6: E2E Test All Untested Forgejo Trigger Scenarios
Issue: #6 Priority: High Created: 2026-02-25
Problem
The Forgejo platform support (PRD #1) was validated for the two most common scenarios (agent mode via workflow_dispatch and tag mode via issue_comment). However, 5 trigger scenarios remain untested in a live environment:
- PR review comment triggers (
pull_request_review_comment) - PR review triggers (
pull_request_review) - Label triggers (
issueswithlabeledaction) - Assignee triggers (
issueswithassignedaction) - Branch creation + code changes from tag mode (the initial test only asked a question, no code was generated)
These untested paths could have silent failures — the code may look correct but break on Forgejo's subtly different webhook payloads, API responses, or event structures.
Solution
Systematically exercise each untested scenario on the live Forgejo instance (git.wxs.ro), document results, fix any issues discovered, and update the E2E status table in docs/forgejo.md.
Milestones
-
M1: Ensure workflow covers all trigger types
- Review
.forgejo/workflows/claude.ymlto confirm all 5 trigger types are listed - Add any missing triggers to the workflow file
- Ensure the workflow has the correct permissions for each trigger type
- Validation: Workflow YAML includes all required
on:triggers
- Review
-
M1.5: Fix image-downloader test failures blocking CI
- Problem: All 18
downloadCommentImagestests failed on Forgejo CI (Linux Bun 1.2.21 inharbor.wxs.ro/wxs/grunt-runner:v1.9.0) while passing locally on macOS. This blocks all PRs. - What we know: On this Linux Docker image,
mock()andspyOn()call tracking frombun:testis broken for this file. Even with DI (no module-level mocking at all), mock functions report "not called" despite being invoked. The ONLY passing test uses a negative assertion. This is NOT amock.moduleissue — it affects plainmock()functions passed as parameters too. - History of failed attempts (5 so far):
- Upstream uses
spyOn(fs, "mkdir")— works on GitHub CI (Bun 1.2.12/ubuntu) but fails on Forgejo Linux 96ec04etried_fsForTestmutable export — abandonedcff360dtried dependency injection for fs mocks — still failed on CIdab92eftriedmock.module("fs/promises")— works on macOS, fails on Linuxc6ca8a7removedmock.moduleentirely, used DI withfsDepsparam — still fails on CI (mock tracking broken at a deeper level)
- Upstream uses
- Next step: Set up local Docker reproduction using
grunt-runner:v1.9.0to debug interactively - Validation: Pending — need local Docker repro first
- Problem: All 18
-
M2: Test PR review comment trigger
- Create a test PR on the repo
- Post a review comment with
@claudemention - Verify: platform detection, context fetching (PR diff, review comment body), tracking comment, Claude response
- Document any issues and fix them
- Validation: Claude responds correctly to
@claudein a PR review comment
-
M3: Test PR review trigger
- Create a test PR on the repo
- Submit a review with
@claudemention in the review body - Verify: platform detection, context fetching, tracking comment, Claude response
- Document any issues and fix them
- Validation: Claude responds correctly to
@claudein a PR review
-
M4: Test label trigger
- Create a label (e.g.,
claude) that triggers the action when applied to an issue - Apply the label to a test issue
- Verify: trigger detection, context fetching (issue body/title), Claude response
- Document any issues and fix them
- Validation: Claude responds when the configured label is applied to an issue
- Create a label (e.g.,
-
M5: Test assignee trigger
- Assign a user to an issue to trigger the action
- Verify: trigger detection, context fetching, Claude response
- Document any issues and fix them
- Validation: Claude responds when assigned to an issue
-
M6: Test tag mode with code changes (branch creation)
- Create an issue requesting a code change (e.g., "add a comment to file X")
- Trigger Claude via
@claudemention - Verify: Claude creates a branch, pushes commits, links the branch in tracking comment
- Verify the Forgejo-specific PR compare URL format is correct
- Validation: Claude successfully creates a branch with code changes on Forgejo
-
M7: Update documentation with E2E results
- Update
docs/forgejo.mdE2E status table with results for all 5 scenarios - Move tested items from "Not Yet E2E Tested" to the validated table
- Document any Forgejo-specific quirks or limitations discovered
- Add troubleshooting entries for any issues encountered
- Validation:
docs/forgejo.mdaccurately reflects the current E2E validation status
- Update
Dependencies
- PRD #5 (Dedicated Forgejo User) is recommended but not strictly required — tests can run with the current token setup
- A test repository on git.wxs.ro with the action workflow configured
Risks
| Risk | Mitigation |
|---|---|
| Forgejo webhook payloads differ from expected | Log raw payloads, compare with GitHub format, adapt parsing |
| Trigger type not supported by Forgejo Actions | Document as known limitation, skip gracefully |
| Action creates unwanted branches/comments during testing | Use a dedicated test repo or clean up after each test |
| Bun mock.module breaks mock tracking on Linux | Use dependency injection for fs mocks, never mock.module |
Success Criteria
- All 5 previously untested scenarios have been exercised on a live Forgejo instance
- Any bugs discovered are fixed and tested
docs/forgejo.mdE2E status table is fully up-to-date- "Not Yet E2E Tested" section is empty (all items moved to validated or documented as unsupported)