Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Add integration and discoverability coverage for Jenkins/GlitchTip MCP clients #155

New Issue
Closed
opened 2026-07-05 01:58:05 -05:00 by jcwalker3 · 2 comments
jcwalker3 commented 2026-07-05 01:58:05 -05:00
Owner
Copy Link
Copy Source

Context

Child implementation issue from the accepted Jenkins/GlitchTip MCP audit decision.

The accepted audit status is the working source of truth:

  • Jenkins and GlitchTip server code exists, but client usability is not proven by configured registration/discovery coverage.
  • jenkins-readonly and glitchtip-readonly do not exist as registered server names unless deliberately added later.
  • No automatic client registration exists through pyproject.toml entry points or repo docs.
  • Tools must not be claimed usable by LLM clients until registration and discoverability are proven.

Scope

  • Add tests, scripts, or validation fixtures proving configured MCP clients can see expected Jenkins tools.
  • Add tests, scripts, or validation fixtures proving configured MCP clients can see expected GlitchTip tools.
  • Include negative assertions for enabled-but-empty or misregistered server configurations.
  • Include reload/reconnect validation instructions for Codex, Gemini, Grok, and other clients as applicable.
  • Keep coverage aligned with the canonical server names and capability boundaries decided by #151 and #152.

Acceptance criteria

  • Discoverability coverage verifies the expected Jenkins tool list through a configured MCP client path.
  • Discoverability coverage verifies the expected GlitchTip tool list through a configured MCP client path.
  • Coverage fails when a server is configured but exposes no usable tools.
  • Coverage fails when docs/config refer to stale server names that are not actually registered.
  • Validation output is operator-friendly enough to diagnose missing entry points, wrong server names, and client reload/reconnect problems.
  • Runbook instructions explain how to reload/reconnect each relevant client after registration changes.

Non-goals

  • Do not implement the core registration/naming decision here; that belongs to #151.
  • Do not correct Jenkins trigger safety here; that belongs to #152.
  • Do not complete GlitchTip filing orchestration here; that belongs to #153.
  • Do not use discoverability alone to claim mutation paths are audited or safe.

Ordering

This is implementation issue 5 of 5. It can proceed alongside or immediately after #151-#153, but final assertions must match the names and boundaries selected there.

## Context Child implementation issue from the accepted Jenkins/GlitchTip MCP audit decision. The accepted audit status is the working source of truth: - Jenkins and GlitchTip server code exists, but client usability is not proven by configured registration/discovery coverage. - `jenkins-readonly` and `glitchtip-readonly` do not exist as registered server names unless deliberately added later. - No automatic client registration exists through `pyproject.toml` entry points or repo docs. - Tools must not be claimed usable by LLM clients until registration and discoverability are proven. ## Scope - Add tests, scripts, or validation fixtures proving configured MCP clients can see expected Jenkins tools. - Add tests, scripts, or validation fixtures proving configured MCP clients can see expected GlitchTip tools. - Include negative assertions for enabled-but-empty or misregistered server configurations. - Include reload/reconnect validation instructions for Codex, Gemini, Grok, and other clients as applicable. - Keep coverage aligned with the canonical server names and capability boundaries decided by #151 and #152. ## Acceptance criteria - Discoverability coverage verifies the expected Jenkins tool list through a configured MCP client path. - Discoverability coverage verifies the expected GlitchTip tool list through a configured MCP client path. - Coverage fails when a server is configured but exposes no usable tools. - Coverage fails when docs/config refer to stale server names that are not actually registered. - Validation output is operator-friendly enough to diagnose missing entry points, wrong server names, and client reload/reconnect problems. - Runbook instructions explain how to reload/reconnect each relevant client after registration changes. ## Non-goals - Do not implement the core registration/naming decision here; that belongs to #151. - Do not correct Jenkins trigger safety here; that belongs to #152. - Do not complete GlitchTip filing orchestration here; that belongs to #153. - Do not use discoverability alone to claim mutation paths are audited or safe. ## Ordering This is implementation issue 5 of 5. It can proceed alongside or immediately after #151-#153, but final assertions must match the names and boundaries selected there.
jcwalker3 added the mcpdocumentationtestingintegrationreliabilityjenkinsglitchtip labels 2026-07-05 01:58:09 -05:00
jcwalker3 commented 2026-07-06 10:46:15 -05:00
Author
Owner
Copy Link
Copy Source

Duplicate triage: closing #150 as a duplicate of this issue. #150 ("Add integration/discoverability coverage") carried three acceptance bullets — client-visibility tests, negative "enabled but no usable tools" assertions, reload/reconnect instructions — all present in this issue's fuller criteria.

Unique content preserved from #150's thread: work was previously started under #150 — branch feat/issue-150-add-integration-discoverability-coverage, and merged PR #190 (merge 9a35b80e9a2616ea41a36ff00061dae0177d4a6f, 2026-07-05) landed the registration naming fix (jenkins-mcp/glitchtip-mcp in the operator guide), client reload/reconnect instructions, and one negative discoverability assertion — but that PR formally closed #146, not #150. Remaining scope (client-path tool-list verification for both servers, stale-server-name failure, operator-friendly diagnostics, runbook reload instructions per client) continues here. This issue remains the canonical tracker; final assertions must match the #151/#152 naming decisions per its ordering note.

Triage by jcwalker3 / prgs-author; duplicate-check evidence: full open-issue inventory, side-by-side body comparison, live PR #190 state.

Duplicate triage: closing #150 as a duplicate of this issue. #150 ("Add integration/discoverability coverage") carried three acceptance bullets — client-visibility tests, negative "enabled but no usable tools" assertions, reload/reconnect instructions — all present in this issue's fuller criteria. **Unique content preserved from #150's thread:** work was previously started under #150 — branch `feat/issue-150-add-integration-discoverability-coverage`, and merged **PR #190** (merge `9a35b80e9a2616ea41a36ff00061dae0177d4a6f`, 2026-07-05) landed the registration naming fix (`jenkins-mcp`/`glitchtip-mcp` in the operator guide), client reload/reconnect instructions, and one negative discoverability assertion — but that PR formally closed **#146**, not #150. Remaining scope (client-path tool-list verification for both servers, stale-server-name failure, operator-friendly diagnostics, runbook reload instructions per client) continues here. This issue remains the canonical tracker; final assertions must match the #151/#152 naming decisions per its ordering note. Triage by `jcwalker3 / prgs-author`; duplicate-check evidence: full open-issue inventory, side-by-side body comparison, live PR #190 state.
jcwalker3 added the status:in-progress label 2026-07-06 11:35:11 -05:00
sysadmin commented 2026-07-06 11:39:02 -05:00
Owner
Copy Link
Copy Source

Claim-state disclosure — possible phantom status:in-progress label

Timeline from an author session (jcwalker3/prgs-author via gitea-tools MCP) on 2026-07-06 ~12:0x:

  1. Issue inventory listed #155 without status:in-progress.
  2. Fresh-selection classification passed (#188 wall: no open PR references #155), so this session attempted to claim it.
  3. gitea_mark_issue(155, start) failed twice with: Pre-flight order violation: Workspace file edits occurred before gitea_resolve_task_capability verification (fail closed) — the sticky-gate behavior tracked in #252 (the "workspace edits" were unrelated reviewer-phase scratch-worktree/memory writes, and the block persisted after gitea_resolve_task_capability returned allowed_in_current_session: true).
  4. Immediately after, gitea-tools MCP went fully unavailable (health check: unresolved merge conflict in gitea_mcp_server.py in the shared workspace — a concurrent session appears to be mid-merge there).
  5. A re-read of #155 now shows status:in-progress present.

Two possible explanations, and I cannot distinguish them from here:

  • my first mark_issue call applied the label before the pre-flight gate raised (mutation-then-fail — if so, that is additional evidence for #252 and worth a test: the gate must run before any label mutation), or
  • another session claimed #155 legitimately in the same window.

No work has been started on #155 by this session — no branch, no lock, no commits. If no other session is actively working it, treat the label as stale/phantom and clear it before the next selection pass. Referencing #252 for the gate behavior.

## Claim-state disclosure — possible phantom `status:in-progress` label Timeline from an author session (`jcwalker3`/prgs-author via gitea-tools MCP) on 2026-07-06 ~12:0x: 1. Issue inventory listed #155 **without** `status:in-progress`. 2. Fresh-selection classification passed (#188 wall: no open PR references #155), so this session attempted to claim it. 3. `gitea_mark_issue(155, start)` failed twice with: `Pre-flight order violation: Workspace file edits occurred before gitea_resolve_task_capability verification (fail closed)` — the sticky-gate behavior tracked in **#252** (the "workspace edits" were unrelated reviewer-phase scratch-worktree/memory writes, and the block persisted after `gitea_resolve_task_capability` returned `allowed_in_current_session: true`). 4. Immediately after, gitea-tools MCP went fully unavailable (health check: unresolved merge conflict in `gitea_mcp_server.py` in the shared workspace — a concurrent session appears to be mid-merge there). 5. A re-read of #155 now shows `status:in-progress` **present**. Two possible explanations, and I cannot distinguish them from here: - my first `mark_issue` call applied the label **before** the pre-flight gate raised (mutation-then-fail — if so, that is additional evidence for #252 and worth a test: the gate must run before any label mutation), or - another session claimed #155 legitimately in the same window. **No work has been started on #155 by this session** — no branch, no lock, no commits. If no other session is actively working it, treat the label as stale/phantom and clear it before the next selection pass. Referencing #252 for the gate behavior.
sysadmin removed the status:in-progress label 2026-07-06 12:28:44 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels documentation glitchtip integration jenkins mcp reliability testing
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#155