Conversation
GitLab's runner jobs(statuses:) argument is [CiJobStatus!], but the ListRunnerJobs query declared $statuses as a singular CiJobStatus. GitLab rejects the query with "List dimension mismatch on variable $statuses" whenever a runner with executed jobs exists, so browse_runners list_jobs failed against real data regardless of whether a status filter was passed. Declare the variable as [CiJobStatus!] and wrap the single-status filter in a list before sending. The unit test now asserts the value reaches GitLab as ["FAILED"] rather than the bare enum. Closes #535
- graphql 16.14.2 -> 17.0.1 (resolves Dependabot #532 / #533). Node engine already requires >=24, which graphql 17 supports. - graphql-tag 2.12.6 -> 2.12.7 so its peer range covers graphql 17. - @clack/prompts 1.5.1 -> 1.6.0. - @cloudflare/workers-types and @types/node patch refresh (within ^25). Verified with the full unit suite (5206 tests) and full integration suite (443 tests) against a live GitLab instance.
…READMEs The MCP Registry listing is driven by server.json's description, which read "GitLab MCP server with 58 tools for projects, MRs, pipelines, and more". That undersells the server next to the README hero line. prepare-release.sh now generates the description from the live tool / operation / entity counts as "<tools> CQRS tools exposing <operations> GitLab operations across <entities> entity types", mirroring the README and staying under the registry's 100-char description limit. prepare-release.sh renders the README to all three shipping locations (core npm page, GitHub repo landing, db npm page), but the release sync job only staged the core README, so the root and db pages drifted a release behind (download badge still on 9.0.0 while core was 9.1.0). Stage all three so the public counts and version stay consistent across npm, GitHub, and the db page. server.json and the root/db READMEs are regenerated here to the current counts.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughFixes the ChangesRunner list_jobs statuses type fix
Release tooling, metadata, and dependency updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Test Coverage ReportOverall Coverage: 96.84%
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
The resolved form-data 4.0.5 is in the vulnerable range (>= 4.0.0, < 4.0.6) for the CRLF-injection-via-multipart-field-names advisory (GHSA, high). Pin it to >=4.0.6 in root resolutions so the dev/CI tree no longer trips the alert. js-yaml's quadratic-merge-key DoS (medium) is left as-is: the only consumer is @istanbuljs/load-nyc-config (dev coverage tooling, parses trusted local config), its sole patch lives in js-yaml 4.x, and forcing that major would break the 3.x safeLoad API the loader relies on.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@package.json`:
- Line 17: The `form-data` dependency in the `resolutions` field uses an
unbounded semver range `>=4.0.6` which permits major version upgrades and
increases the risk of breaking changes on lockfile refreshes. Change the version
specifier from `>=4.0.6` to `^4.0.6` in the `resolutions` object to establish a
bounded range that maintains the security floor while preventing accidental
major-version upgrades. This follows semantic versioning best practices by
allowing patch and minor version updates while locking the major version at 4.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: d258c41d-df28-4c88-b13d-7cb71f431d59
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (1)
package.json
|
| Filename | Overview |
|---|---|
| packages/gitlab-mcp/src/graphql/runners.ts | Fixes the ListRunnerJobs query: changes $statuses variable type from CiJobStatus to [CiJobStatus!] and updates the TypeScript interface from string to string[], matching GitLab's actual API contract. |
| packages/gitlab-mcp/src/entities/runners/schema-readonly.ts | Updates ListRunnerJobsSchema to accept statuses as an array of enums rather than a single enum, enabling multi-status filtering and matching the adopted recommendation from a previous review thread. |
| packages/gitlab-mcp/tests/unit/entities/runners/registry.test.ts | Test updated to pass statuses as an array (["FAILED", "CANCELED"]) and assert the variable is forwarded as-is to the GraphQL query. |
| packages/gitlab-mcp/scripts/prepare-release.sh | server.json description now auto-generated with live tool/operation/entity counts; renders README to all three shipping locations instead of just the core package page. |
| .github/workflows/release-please.yml | Release PR sync step now stages root and db READMEs in addition to the core README, preventing them from drifting a release behind. |
| packages/gitlab-mcp/package.json | Bumps graphql 16→17, graphql-tag 2.12.6→2.12.7, @clack/prompts 1.5.1→1.6.0, and patch bumps to @cloudflare/workers-types and @types/node. |
| package.json | Adds form-data ^4.0.6 to the monorepo root resolutions map to pin the transitive dependency version brought in by the graphql 17 upgrade. |
Reviews (2): Last reviewed commit: "fix(runners): accept multiple job status..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
GitLab's jobs(statuses:) argument is [CiJobStatus!], so it natively filters by more than one status. The list_jobs schema now takes an array of statuses instead of a single value, and the handler forwards it straight through. Callers can request e.g. ["FAILED", "CANCELED"] in one query.
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
1 participant
Closes #535. Bundles four maintenance items into a single PR.
1. server.json marketing copy is now auto-generated (most important)
The MCP Registry listing is driven by
server.json'sdescription, which read:That undersells the server next to the README hero line.
prepare-release.shnow generates the description from the live tool / operation / entity counts:
This mirrors the README and stays under the MCP Registry's 100-char description
limit (67 chars here, and well under even with 3-digit counts).
2. All marketing READMEs are committed at release
prepare-release.shrenders the README to three shipping locations (core npmpage, GitHub repo landing, db npm page), but the release sync job only staged
the core README. The root and db READMEs drifted a release behind: their
download badge still pointed at 9.0.0 while the core page was on 9.1.0. The sync
job now stages all three, and they are regenerated here to the current version.
3. graphql 16 -> 17 (Dependabot #532 / #533)
graphql16.14.2 -> 17.0.1,graphql-tag2.12.6 -> 2.12.7 (its peer rangenow covers graphql 17). The package engine already requires Node >=24, which
graphql 17 supports, so there is no engine regression.
@clack/prompts1.5.1 -> 1.6.0, plus@cloudflare/workers-typesand
@types/nodepatch bumps (within^25).@types/node26 and
nx23.This supersedes Dependabot PRs #532 and #533; both will be closed.
4. Runner job-status query fix
Found while running the full integration suite.
browse_runnersactionlist_jobsdeclared$statuses: CiJobStatus, but GitLab'sjobs(statuses:)argument is
[CiJobStatus!]. GitLab rejects the query with "List dimensionmismatch on variable $statuses" whenever a runner with executed jobs exists,
independent of the value sent. This is a pre-existing bug (the query text is
identical on graphql 16 and 17, so it is not caused by the upgrade) that only
surfaced once the test instance had a runner with jobs. Fixed by declaring the
variable as
[CiJobStatus!]and wrapping the single-status filter in a list.Testing
(39 suites) on graphql 17, including the previously failing runner drill-down.
yarn buildandyarn lintclean.prepare-release.sh 9.1.0runs clean:58 tools (32 read-only, 230 actions), 26 entities.Summary by CodeRabbit
New Features
Documentation
Chores