Breaking changes addressed:
- raw.NewClient: Use WithHTTPClient/WithEnterpriseURLs options, pass ctx to
NewRequest, return (*Client, error)
- internal/ghmcp/server.go: Use functional options for REST client creation,
replace UserAgent field mutation with UserAgentTransport wrapper, add
restUATransp field to githubClients struct
- pkg/github/dependencies.go: Use functional options for REST client creation,
handle raw.NewClient error return
- pkg/github/actions.go: Handle new WorkflowDispatchRunDetails return value
from CreateWorkflowDispatchEventByID/ByFileName
- pkg/github/issues.go: Replace IssueListOptions with ListOptions for
SubIssue.ListByIssue
- pkg/github/notifications.go: MarkThreadDone now takes string instead of
int64; remove ParseInt and strconv import
- pkg/github/projects.go: Remove pointer indirection from
ListProjectsPaginationOptions and ListProjectsOptions fields
- pkg/github/issues_granular.go: Pass ctx to NewRequest, remove ctx from Do
- Test files: Add mustNewGHClient helper, replace all NewClient calls,
fix stubClientFnFromHTTP signature, fix lockdown_test.go BaseURL handling,
fix raw_test.go, remove invalid threadID test case
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add ifc label for search_issues tool
Emits an IFC SecurityLabel on the search_issues tool result when the
InsidersMode flag is enabled, mirroring the pattern landed for get_me
in #2432, list_issues in #2453, and get_file_contents in #2454.
Search results may span multiple repositories, so the label is the IFC
join of the per-repository labels:
- Integrity is always untrusted (issues are user-authored).
- If any matched repository is public, the joined readers are
["public"] (the public side dominates the lub).
- Otherwise the joined readers are the intersection of the
collaborator sets across all matched private repositories.
- Empty result sets are labelled public-untrusted (no data leaked).
The shared searchHandler in search_utils.go gains an additive variadic
'searchOption' hook so SearchIssues can attach _meta.ifc without
duplicating the search call. SearchPullRequests is unaffected; it does
not pass any options.
If any per-repository visibility or collaborators lookup fails the label
is omitted entirely, consistent with get_file_contents, to avoid
misclassifying the result.
Refs github/copilot-mcp-core#1623, github/copilot-mcp-core#1389.
Note: this PR is chained on #2454 (gokhanarkan/fides-get-file-contents)
because it depends on the FetchRepoIsPrivate and FetchRepoCollaborators
helpers introduced there. GitHub will retarget the base to main once
#2454 merges.
* search_issues: address Copilot review findings
- LabelSearchIssues now returns (SecurityLabel, bool); the bool is
false when len(repoVisibilities) != len(readerSets), so callers can
omit the label rather than emit one computed from inconsistent
inputs.
- searchIssuesIFCPostProcess no longer substitutes [owner] when the
collaborators API returns an empty list. The substitution was
inconsistent with the cross-repo intersection semantics: the owner
could appear in another matched private repo's collaborator list and
thereby widen the joined reader set incorrectly. Empty collaborator
sets are now passed through unchanged.
- Add a subtest exercising the collaborators-failure branch (500 on
/repos/{owner}/{repo}/collaborators), asserting the tool still
succeeds and result.Meta["ifc"] is absent.
- Extend the LabelSearchIssues table tests with the slice-length
mismatch case.
Addresses the three Copilot findings on #2456.
* search_issues: flip IFC join to intersection (private wins)
Address Joanna's review feedback on #2456: a reader of a multi-repo result
must be authorised to read every matched private repository, so the IFC
join is the meet (intersection over private repos) rather than the join.
Public matches contribute the universe set and drop out of the
intersection without shrinking it.
- LabelSearchIssues: collect only the private reader sets, then intersect.
Empty result and all-public remain public-untrusted.
- TestLabelSearchIssues: flip the mixed public+private expectation and add
a 'two private + one public' case to lock in the new semantics.
- Test_SearchIssues_IFC_InsidersMode: mixed subtest now expects the
private repo's reader set instead of public.
* Bump google/go-github
* chore: regenerate license files
Auto-generated by license-check workflow
* Fix required block
* Go mod vendor and tidy again
* Remove unused fatih/color dependency to fix CI (#2005)
* Initial plan
* Remove unused github.com/fatih/color dependency
The fatih/color package was listed in go.mod but not actually imported
or used anywhere in the codebase. This caused the CI "go mod tidy -diff"
check to fail. Running go mod tidy removed:
- github.com/fatih/color v1.18.0
- github.com/mattn/go-colorable v0.1.13 (transitive)
- github.com/mattn/go-isatty v0.0.20 (transitive)
Fixes the failing ubuntu-latest workflow build.
Co-authored-by: JoannaaKL <67866556+JoannaaKL@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoannaaKL <67866556+JoannaaKL@users.noreply.github.com>
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Add NewGitHubAPIStatusErrorResponse helper function to properly track
GitHub API errors when the API call succeeds but returns an unexpected
HTTP status code (e.g., 404, 422, 500).
Previously, these errors were returned via utils.NewToolResultError which
bypasses the context-based error tracking used by the remote server's
error_categorizer.go for observability metrics. This resulted in 100%
tool call success rates in observability even when errors occurred.
The fix adds a new helper function that:
1. Creates a synthetic error from the status code and response body
2. Records the error in context via NewGitHubAPIErrorResponse
3. Returns the MCP error result to the client
Updated all tool files to use the new pattern for status code errors:
- pullrequests.go: 12 fixes
- repositories.go: 18 fixes
- issues.go: 10 fixes
- notifications.go: 6 fixes
- projects.go: 5 fixes
- search.go: 3 fixes
- search_utils.go: 1 fix
- gists.go: 4 fixes
- code_scanning.go: 2 fixes
- dependabot.go: 2 fixes
- secret_scanning.go: 2 fixes
- security_advisories.go: 4 fixes
Total: ~69 error paths now properly tracked.
Note: Parameter validation errors (RequiredParam failures) and internal
I/O errors (io.ReadAll failures) intentionally continue to use
utils.NewToolResultError as they are not GitHub API errors.
* updates github-mcp-server to go-github/v76
* updates license files
* refactors ListProjects to make use of
google/go-github ProjectsService
* refactors GetProject to make use of google/go-github ProjectsService
* declaring commit without a pointer
* cleanup additional commit pointer
---------
Co-authored-by: Tommaso Moro <37270480+tommaso-moro@users.noreply.github.com>
* Enhance search functionality with new query filters and utility functions
- Added multiple test cases for searching issues with various query filters in `issues_test.go`.
- Introduced utility functions in `search_utils.go` to check for specific filters and extract repository information from queries.
- Created comprehensive tests in `search_utils_test.go` to validate the new filtering logic and ensure accurate query parsing.
* Refactor repository filter extraction in search utilities
- Renamed `extractRepoFilter` to `hasRepoFilter` to simplify the function's purpose.
- Updated test cases in `search_utils_test.go` to reflect the new function name and logic.
- Adjusted tests to focus on the presence of the `repo:` filter rather than extracting owner and repo details.
* Enhance search functionality with additional query filters and utility functions
- Added new test cases for searching pull requests and users with various query filters in `pullrequests_test.go` and `search_test.go`.
- Implemented a utility function `hasTypeFilter` in `search_utils.go` to check for the presence of `type:` filters in queries.
- Updated the search handler to conditionally prepend the `type:` filter based on the presence of existing filters, improving query handling.
* Updated both regex patterns to handle this edge case
Kelsey Myers