Add GitHub issue types support with GraphQL integration - #20
Merged
briandominick merged 3 commits intoJul 16, 2025
Merged
Conversation
- Add 'type' field to Issue model with defaults support - Create GitHub API client with GraphQL query support using HTTP requests - Add hybrid API approach: GraphQL for issues with types, REST for others - Implement case-insensitive type matching (bug, BUG, Bug all work) - Add graceful fallback from GraphQL to REST API on errors - Add type label fallback: creates 'type:<type>' label when GraphQL fails - Support type field in GitHub site adapter parameter conversion - Remove redundant repository field from dry-run output formatting - Add type display in formatted output when present
- Add 'type' field to IMYML format examples and property reference - Document type field in defaults and individual issue records
- Add 11 new tests in issue_spec.rb for type field behavior and site integration - Add 4 tests for type model support (defaults, preferences, nil handling) - Add 4 tests for GitHub site adapter type parameter conversion - Add 3 tests for dry-run display formatting with types - Add 2 tests in ops_spec.rb for case-insensitive type matching logic
briandominick
added a commit
that referenced
this pull request
Aug 7, 2025
* Bump version to 0.2.0 * Ignore local AI scratch path * Clean up .gitignore * fix: correct examples link path in README * chore: update Gemfile.lock for version 0.2.0 * Add GitHub issue types support with GraphQL integration (#20) * doc: add issue types support to IMYML documentation * test: add comprehensive test coverage for issue types feature * fix: 'JIRA'->'Jira' references (#23) * Add capability to override default tags on a per-issue basis (#24) * add: tag removal functionality with - prefix at issue level * test: add comprehensive tests for tag removal functionality * doc: add tag removal example to README * Fix long-line wrapping in dry-run output with maintained indentation (#25) * Docs/issues README review and GemDocs links (#30) * Remove -v and --tokenv from CLI help (#31) * Remove parentheses around method def args * Updated examples to include types * Add ReleaseHx functionality for generating release notes/changelog
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds support for GitHub issue types with GraphQL integration and fallback behavior.
GraphQL Note
The
typeproperty of GitHub issues is relatively new, and it has not yet been implemented in the REST API. At first I thought it was just not documented, but after some experimentation I'm confident it is not there for write (POST/PUT/DELETE) operations, though it is returned inGETrequests for issues.The GraphQL API does support assigning types to issues, so I have implemented it that way. This does mean having a single operation (method:
Issuer::APIs::GitHub::Client.create_issue_with_type) that engages the GraphQL API.When I add Jira support, we'll be using REST, so there's no reason to scrap REST altogether. However, it is tempting to switch to GraphQL for all GH operations. For now, this quirky fix is what I decided was called for. If the GraphQL operation fails, the fallback is to REST with a
type:<type>label added to rescue the operation. This technically means usingtype: Taskortype: Anythingin an IMML document is a way to arbitrarily assigntype:-keyed labels, but there is really no advantage to that over just adding a labeltype:Taskor whatever.Changes
Core Features
GraphQL Integration
Testing & Documentation
User Experience
This feature maintains maximum compatibility with GitHub's current issue model while adding flexible issue typing support within the Issuer tool.