Integrate Existing Github Client as Eliza Plugin

[jkbrooks]

Ticket: Integrate Existing GitHub Client as Eliza Plugin

Description:

This ticket focuses on integrating the existing GitHubClient (located in packages/client-github/src/index.ts) into the Eliza framework as a plugin. This will enable Eliza agents to interact with GitHub repositories for various tasks, as outlined in the GitHub Plugin Epic.

Acceptance Criteria:

• The GitHubClient is packaged as an Eliza plugin, adhering to Eliza's plugin structure and interface.
• The plugin is registered within Eliza and can be loaded and initialized correctly.
• The plugin's provider, client, actions, and evaluators (if any) are properly registered with Eliza's runtime.
• The plugin's functionalities (fetching data, creating/modifying issues, etc.) can be accessed and used by Eliza agents.
• Unit and integration tests are added to verify the plugin's functionality and integration with Eliza.
• Documentation is updated to include instructions on how to use and configure the GitHub plugin.

Tasks:

1. Create Plugin Structure: Create a new directory for the GitHub plugin (e.g., packages/plugin-github). Create the necessary files for the plugin (e.g., index.ts, potentially separate files for actions, providers, and evaluators).

2. Adapt GitHubClient (if necessary): Review the existing GitHubClient and ensure it adheres to Eliza's Client interface. If necessary, adapt the client's methods (start, stop, sendMessage, handleMessage) to be compatible with Eliza's message handling and event processing. Pay particular attention to the handleMessage function, as it needs to integrate with Eliza's OODA loop. Ensure the client emits the necessary events to trigger Eliza's workflows.

3. Create GitHub Provider: Create a GitHub provider class that implements the Provider interface. This provider will be responsible for fetching data from the GitHub API and transforming it into Eliza-compatible Memory objects. Initially, focus on fetching basic repository data (e.g., issues, commits). Authentication, pagination, and error handling should be implemented in the provider. Defer caching and rate limiting to later tickets. Consider leveraging the existing createMemoriesFromFiles function as a starting point for fetching and transforming data.

4. Define and Register Actions: Define and implement the core GitHub actions (CREATE_ISSUE, MODIFY_ISSUE, ADD_COMMENT) within the plugin. Ensure that the action handlers use the GitHubClient to interact with the GitHub API. Register these actions within the plugin's index.ts file.

5. Register Plugin with Eliza: In Eliza's core, add the necessary logic to register and load the GitHub plugin. Ensure that the plugin's components (provider, client, actions) are correctly registered with the Eliza runtime during plugin initialization.

6. Implement Unit and Integration Tests: Write unit tests for the provider, client, and actions. Write integration tests to verify the plugin's interaction with Eliza's core functionalities (OODA loop, message processing, etc.).

7. Update Documentation: Update Eliza's documentation to include instructions on how to install, configure, and use the GitHub plugin. Provide example character configurations and use cases.

8. Implement Core API Interactions: Implement the following core interactions with the GitHub API within the client and/or provider:

   • Fetch Code: Use the GET /repos/{owner}/{repo}/contents/{path} API to retrieve code from the specified repository. Implement logic to handle different file types and potential errors (e.g., file not found, rate limiting). Consider adding support for fetching specific commits or branches.

   • Fetch Issues: Use the GET /repos/{owner}/{repo}/issues API to retrieve a list of issues from the repository. Implement pagination and filtering (e.g., by status, labels, assignees) to handle large repositories and specific queries.

   • Create/Modify Issues: Use the POST /repos/{owner}/{repo}/issues API to create new issues and the PATCH /repos/{owner}/{repo}/issues/{issue_number} API to modify existing issues. Ensure the agent can set the issue title, body, labels, and assignees (if applicable).

9. Implement Stretch Goal API Interactions (Optional): If time and resources permit, explore integrating the following APIs:

   • Pull Requests API: GET /repos/{owner}/{repo}/pulls (for fetching pull requests) and POST /repos/{owner}/{repo}/pulls (for creating pull requests).

   • Labels API: GET /repos/{owner}/{repo}/labels (for fetching labels) and POST /repos/{owner}/{repo}/issues/{issue_number}/labels (for adding labels to issues).

   • Repository API: GET /repos/{owner}/{repo} (for fetching repository metadata).

   • Commits API: GET /repos/{owner}/{repo}/commits (for fetching commit history).

Technical Considerations:

• Eliza Plugin Structure: Refer to Eliza's plugin documentation and examples for guidance on the plugin structure and interface.

• Client Interface: Ensure the GitHubClient adheres to the Client interface defined in Eliza's core.

• Provider Interface: The GitHub provider must implement the Provider interface.

• Action Interface: Ensure the GitHub actions adhere to the Action interface.

• Memory Objects: Use Eliza's Memory object to represent GitHub data. Consider creating custom Content subtypes for different GitHub data types.

• Asynchronous Operations: Use async/await and promises for all asynchronous operations (API calls, event handling).

• Error Handling: Implement robust error handling and retry mechanisms for all GitHub API interactions.

• TypeScript Best Practices: Follow TypeScript best practices for type safety, code readability, and maintainability.

• API Rate Limiting: Implement basic rate-limiting handling for the core API interactions. This can be expanded in later tickets.

• Data Transformation: Ensure that the data fetched from the GitHub API is correctly transformed into Eliza-compatible Memory objects. Pay particular attention to the structure of the content field and consider creating custom Content subtypes for different GitHub data types (e.g., GithubIssueContent).

Dependencies:

• This ticket depends on the completion of Ticket 1 in the GitHub Plugin Epic (Investigate Existing GitHub Client).

Open Questions:

• Should the GitHubClient be extended from an existing Eliza client (e.g., DirectClient) or implemented as a standalone client? (This should be addressed in Decision 1 of the epic.)
• How should the handleMessage function in the client be structured to integrate with Eliza's OODA loop?

Notes:

This ticket represents a significant step towards integrating GitHub with Eliza. By implementing the plugin structure and core functionalities, we enable a wide range of future enhancements and integrations. Clear communication and collaboration with other developers are essential for the successful completion of this ticket. Please add any clarifying questions or comments directly to this ticket.

• The core API interactions (fetching code, fetching issues, creating/modifying issues) are essential for the basic functionality of the GitHub plugin and should be prioritized. The stretch goal API interactions can be implemented later or assigned to different developers. Clearly mark these as optional in the ticket to provide flexibility.

  Also note that some of this may have already been implemented by the existing GitHub client.