Create Github Client

[jkbrooks]

Ticket: Implement GitHub Client for Eliza

Priority: High
Status: Open
Assignee: (Assign to a developer)
Due Date: (Set a realistic due date)

Description:

This ticket outlines the implementation of a dedicated GitHub client for the Eliza framework, mirroring the structure and functionality of existing clients like Discord, Telegram, and Twitter. This client will enable Eliza agents to interact with GitHub repositories, providing a foundation for building more sophisticated GitHub-related tools and integrations.

Goals:

• Provide a standardized interface for interacting with the GitHub API within Eliza.
• Enable Eliza agents to perform actions on GitHub repositories, such as creating issues, pull requests, and commits.
• Allow agents to access and process information from GitHub, including repository contents, issue discussions, and commit history.
• Integrate seamlessly with Eliza's existing architecture, including the runtime, memory, and plugin systems.

Acceptance Criteria:

• The GitHub client should be implemented as a separate package (@ai16z/client-github).
• It should implement the Client interface from @ai16z/eliza, ensuring consistency with other clients.
• The client should support authentication using a GitHub personal access token. Securely store this token using Eliza's secrets management.
• It should provide methods for:
  • Fetching repository information (name, description, owner, etc.)
  • Retrieving a list of issues and pull requests
  • Getting details for a specific issue or pull request
  • Creating new issues, pull requests, and comments
  • Accessing file contents and commit history
• The client should handle rate limiting and other API limitations gracefully.
• Integration tests should be written to verify core functionality.
• Documentation should be added to Eliza's website explaining how to use the client.

Out of Scope (for initial implementation):

• Support for GitHub Actions.
• Integration with GitHub webhooks. (Consider for a future enhancement)
• Complex GitHub operations such as repository management or user administration.

Dependencies:

• @octokit/rest: For interacting with the GitHub API.
• @ai16z/eliza: For core Eliza functionality.
• Other relevant packages based on the specific implementations.

Open Questions and Decision Points:

• How should GitHub-specific data structures be represented within Eliza's memory? (e.g., using custom Content types or existing data models).
• What level of error handling and logging should be implemented?
• Should the client support different authentication methods beyond personal access tokens? (e.g., OAuth).

Tasks:

• Create a new package @ai16z/client-github.
• Implement the Client interface.
• Add authentication logic.
• Implement core methods for interacting with GitHub.
• Add rate limiting and error handling.
• Write unit and integration tests.
• Add documentation to Eliza's website.

Core API Interaction Methods (All should be moved from the plugin):

• authenticate(token: string): Handles authentication using a GitHub personal access token. (Exists in plugin, slightly different implementation)
• getRepository(owner: string, repo: string): Promise<Repository>: Fetches repository information. (Exists in plugin)
• getIssues(owner: string, repo: string, options?: IssueOptions): Promise<Issue[]>: Retrieves a list of issues. (Exists in plugin)
• getIssue(owner: string, repo: string, issueNumber: number): Promise<Issue>: Gets details for a specific issue. (Exists in plugin)
• createIssue(owner: string, repo: string, title: string, body: string, labels?: string[]): Promise<Issue>: Creates a new issue. (Exists in plugin)
• updateIssue(owner: string, repo: string, issueNumber: number, updates: IssueUpdates): Promise<Issue>: Updates an existing issue. (Exists in plugin as modifyIssue)
• createComment(owner: string, repo: string, issueNumber: number, body: string): Promise<Comment>: Creates a new comment on an issue. (Exists in plugin as addCommentToIssue)
• getPullRequests(owner: string, repo: string, options?: PullRequestOptions): Promise<PullRequest[]>: Retrieves a list of pull requests. (Exists in plugin)
• getPullRequest(owner: string, repo: string, prNumber: number): Promise<PullRequest>: Gets details for a specific pull request. (Not explicitly in plugin, but functionality can be derived)
• createPullRequest(owner: string, repo: string, title: string, head: string, base: string, body?: string): Promise<PullRequest>: Creates a new pull request. (Exists in plugin)
• getFileContents(owner: string, repo: string, path: string, ref?: string): Promise<string>: Accesses file contents at a specific ref (branch/commit). (Exists in plugin)
• getCommits(owner: string, repo: string, options?: CommitOptions): Promise<Commit[]>: Retrieves commit history. (Not in plugin, needs implementation)

Utility Methods (New, or refactor from the plugin):

• getRepoPath(owner: string, repo: string): string: Returns the local file path for a cloned repository. (Exists in plugin)
• cloneOrPullRepository(owner: string, repo: string, localPath: string): Promise<void>: Clones or pulls a repository. (Exists in plugin as initialize, should be refactored to remove memory logic)
• checkoutBranch(repoPath: string, branch?: string): Promise<void>: Checks out a specific branch in a local repository. (Exists in plugin, should be refactored)
• writeFiles(repoPath: string, files: { path: string; content: string }[]): Promise<void>: Writes or overwrites files in a local repository. (Used in multiple plugin actions, needs to be a shared utility)

Data Structures (Define in client package):

Custom Content types: Create GitHub-specific Content subtypes within Eliza's existing Memory model. This is likely the best approach for long-term maintainability and allows Eliza to understand GitHub data as distinct from other content types (Discord messages, tweets, etc.)

• Repository: Interface for repository information.
• Issue: Interface for issue data. Include labels and state (open/closed).
• IssueOptions: Interface for optional parameters to getIssues (e.g., filtering by state, labels, assignees).
• IssueUpdates: Interface for updating an issue (title, body, state, labels).
• Comment: Interface for comment data.
• PullRequest: Interface for pull request data.
• PullRequestOptions: Interface for optional parameters to getPullRequests (e.g., filtering by state, head branch).
• Commit: Interface for commit data.
• CommitOptions: Interface for optional parameters to getCommits (e.g., specifying a branch or date range).

"Refactor Existing Plugin: After the GitHub client is implemented, refactor the @ai16z/plugin-github plugin to use the new client package. This will ensure consistency, reduce code duplication, and make the plugin simpler to maintain."

Related Issues:

• (Link to any related GitHub issues, particularly those regarding the existing GitHub plugin)

Notes:

• Draw inspiration from the existing GitHub plugin (@ai16z/plugin-github) for functionality and implementation patterns.
• Ensure the client adheres to Eliza's overall architecture and coding standards.
• Consider future enhancements beyond the initial scope, such as webhooks and Actions support.

[snobbee]

@jkbrooks @monilpat prepared our new character file "logging addict" as as simpler scenario to test out the github client #107

[snobbee]

@monilpat @jkbrooks PR #108 it is still very basic it registers the github plugin so that one can trigger those plugins action within the client github usage, next would be to incorporate the loop and allow client to use provider to get source code, then analyze the code and create a PR with the new changes related to logging would make sense

[jkbrooks]

Note for testing if you run into context window issues #113 (comment)

If not then it could be fine to ship this as is with OpenAI and then use Gemini later after we do some demos on smaller apps

[jkbrooks]

We are currently trying to get the capacity through the OODA loop to create issues and add comments to issues.

After that, we will potentially try to add PRs and maybe comments to PRs.

We will want to take in all of the issues and all of the comments and pull requests, not just all of the code in the OODA loop. This is a new feature.