Add Support for Github Issues with Repo Mapping to Project#8
Add Support for Github Issues with Repo Mapping to Project#8seuros merged 14 commits intoseuros:masterfrom
Conversation
There was a problem hiding this comment.
Copilot reviewed 56 out of 59 changed files in this pull request and generated 1 comment.
Files not reviewed (3)
- test/fixtures/github_webhook_comment_created.json: Language not supported
- test/fixtures/github_webhook_issue_closed.json: Language not supported
- test/fixtures/github_webhook_issue_opened.json: Language not supported
Comments suppressed due to low confidence (1)
lib/active_project/adapters/github/issues.rb:98
- In 'update_issue', the code updates the issue based solely on the key :status, yet the README usage shows updating with key :state. Consider supporting both keys or standardizing on one attribute name for issue status updates.
def update_issue(id, attributes, context = {})
|
|
||
| # Add a comment | ||
| puts "Adding comment to issue ##{updated_issue.key}..." | ||
| comment = github_adapter.add_comment(updated_issue.key, "This is a comment added via the ActiveProject gem.") |
There was a problem hiding this comment.
The README example demonstrates adding a comment via the GitHub adapter, but no 'add_comment' method is implemented in the adapter. Please add an implementation for 'add_comment' or update the documentation to match supported functionality.
| def initialize(options = {}) | ||
| super | ||
| @status_mappings = options.delete(:status_mappings) || { | ||
| "open" => :open, |
There was a problem hiding this comment.
since it the same, Github don't need mapping. You can omit it like jira and basecamp.
| @@ -4,17 +4,28 @@ module ActiveProject | |||
| # Represents a standardized event parsed from a webhook payload. | |||
| # Using Struct for simplicity for now. Could be a full class inheriting BaseResource if needed. | |||
| WebhookEvent = Struct.new( | |||
There was a problem hiding this comment.
We will rebuild the webhook in a future version, i tested it only in basecamp and jira.
You can remove the Webhook in GH to have the test pass.
There was a problem hiding this comment.
I got the webhooks working I'm pretty sure, I'll double check.
|
Wow, i started analyzing it few hours ago, but i'm happy to have you implement it. GitHub offers two types of Projects:
Let's investigate if we can create a single adapter that handles both types through polymorphism. The adapter could detect the project type and use the appropriate endpoint. If the differences become too complex for a single class, we could implement an inheritance structure with:
This approach would maintain a clean interface while handling the endpoint differences under the hood. |
|
I figured I'd map the concept of a project to a repo with issues on it as I think that's a more common pattern for the idea of projects and tickets/issues in the GitHub world. GitHub projects via the REST API refer to a soon to be deprecated project resource. The new project resource on GitHub is only accessible via the graphql api, which we could implement. But those project objects don't really have issues, they have tasks, which can map to issues. But also those project objects can map to multiple repositories. I thought this implementation mirrors the majority of actual issues and ticket management I've experienced on GitHub. We mostly think in terms of the repo being the project and its issues being tickets. Thoughts? I'll look over the other comments too if they need fixing happy to do it. Also, to be honest, this was 98% vibe coded 😃 hope that's ok! |
|
Vibe coding’s totally fine as long as there’s some underlying research and understanding of the flow. But let’s be honest here, vibe coding has a bad habit of inventing patterns that don’t actually exist and leaving behind more artifact/comments than a hoarder-themed episode of reality TV. It makes future maintenance a bit like an archaeological expedition. The gem’s broader goal is to offer a normalized interface across tools. In reality, 99% of what people actually do in project management tools is create issues/tasks, move them around a board, and leave passive-aggressive comments. The “transformational features” that we see in keynote slides, are mostly used by 12 power users who spend their days on LinkedIn telling everyone how a pastel-colored dashboard increased their team’s productivity by 1000% and to comment "Design" to get a free PDF with the method. For the GitHub adapter: we should probably check when the REST endpoint is actually getting removed before committing to anything. If it’s soon, maybe not worth the effort or the vibes. As for GraphQL, I was planning to explore a base engine so we can layer the other implementation on top of it cleanly. The long-term vision here is to have all these adapters eventually maintained by their respective vendors, once we’ve established a sane standard, for us Rubyists and for our lovely LLM assistants who deserve better than this mess. |
|
It looks like the REST API for Projects was due to be sunset already: https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/#rest-api-timeline So it sounds like a bad idea to use that. I think it would be ideal to actually support both model mappings, where a "Project" could be a repo or it could be a Github project using the GraphQL API and maps to the project and tasks objects of that API and not the repo / issues objects. We could Scope that somehow with two differetn Adadapters, Maybe GithubProjects for the GraphQL and Github Issues for the repo/issues mapping. Anyway, let me know how you want to proceed, I think there's a lot of utility in the repo/issues mapping over the Projects one. |
|
let name this adapter to github_rest and merge it. Can you fix the Webhook error in tests ? We could create a new Struct for Github Wehbhook. |
|
Yep, I'll fix. I'd even consider renaming this adapter GithubRepo and then the GraphQL one for a github project can be GithubProject - that to me feels like a clear seperation for users of which to use - want to use this gem to manage issues on a repo? GithubRepo - want to use this to manage tasks on a github project - GithubProject. |
|
I like this thinking. |
|
@aviflombaum any update on this ? |
Centralized HTTP request handling into a reusable HttpClient module, simplifying and standardizing logic across adapters. Updated adapters (Trello, Basecamp, and Jira) to use the new module, reducing duplication and improving maintainability.
refactor: HTTP logic to use centralized HttpClient module
• add async, async-http & async-http-faraday to gemspec • HttpClient now selects adapter via AP_DEFAULT_ADAPTER (defaults to :net_http) • Pagination mix-in with each_page / each_page_async helpers • ActiveProject::Async.run wrapper for easy task spawning • Trello::Connection: map 400 "invalid id" → NotFoundError (kept in same file) • CI matrix entry with AP_DEFAULT_ADAPTER=async_http
• lib/active_project/railtie.rb sets Fiber scheduler before Zeitwerk • config flag config.active_project.use_async_scheduler (default true) • env-var opt-out AP_NO_ASYNC_SCHEDULER=1 • main file requires railtie only when Rails::Railtie is defined • adds AS::Notifications event "active_project.async_scheduler_set"
feat(core): introduce Async I/O pathway
…ster--components--active_project chore(master): release active_project 0.3.0
* feat: Github project adapter. * feat(github): implement webhook processing for GitHub Projects V2 * Update lib/active_project/adapters/base.rb Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- Renamed github adapter to github_repo in configuration - Merged GitHub adapter functionality with existing github_project - Resolved conflicts in README, configuration, and test files - Combined VCR configuration approaches - Updated test fixtures to use correct adapter names 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2 participants
This PR adds a GitHub adapter to integrate GitHub Issues with ActiveProject. The implementation:
The adapter uses GitHub's REST API v3 and follows ActiveProject's adapter pattern, providing a consistent interface
alongside existing Jira, Trello, and Basecamp adapters.