Reinier van der LeerandClaude Fable 5
5e548164e1
### Why / What / How **Why:** We have GitHub trigger and repo/issue/PR blocks, but no way for agents to work with the user's GitHub notification inbox — e.g. inbox-zero automations, notification triage, or surfacing review requests. GitHub's Notifications API is poll-only (no webhook events exist for it), so inbox automations run as scheduled graphs using regular blocks. **What:** Adds six blocks covering the [GitHub Notifications REST API](https://docs.github.com/en/rest/activity/notifications): listing notifications and getting / marking read / marking done / unsubscribing from notification threads, plus mark-all-as-read. Also adds a `GithubGetUserInfoBlock` and extends `GithubListPRReviewersBlock` with review status info, enabling agents to determine whether the account's user is (still) involved in a PR (example use case: auto-archiving stale review-request notifications). **How:** New `notifications.py` in the GitHub blocks package, following the existing block conventions there. Notification endpoints live under `/notifications` rather than `/repos/...`, so the blocks use `get_api(credentials, convert_urls=False)` with absolute URLs. API responses are normalized into a shared `NotificationItem` shape whose `thread_id` chains into the per-thread blocks and whose `subject_url` is converted best-effort from the API URL to the corresponding github.com page URL. Notification blocks use the minimal `notifications` OAuth scope. ### Changes 🏗️ - Add `GithubListNotificationsBlock`: lists the inbox with include-read / participating-only / `since` / `before` filters and optional repo scoping; yields the full list plus each notification individually - Add `GithubGetNotificationThreadBlock`: fetches one thread and exposes title, reason, unread, subject type/URL, and repository as separate outputs - Add `GithubMarkNotificationsAsReadBlock`: marks all notifications as read, optionally repo-scoped, with optional `last_read_at` cutoff - Add `GithubMarkNotificationThreadAsReadBlock` and `GithubMarkNotificationThreadAsDoneBlock`: per-thread read / done - Add `GithubUnsubscribeNotificationThreadBlock`: mutes a thread - Add `GithubGetUserInfoBlock`: fetches info on a given user, or the authenticated user if no username is given - Extend `GithubListPRReviewersBlock`: new `include_past_reviewers` toggle (default off) to also list users who already submitted a review, plus `review_requested` / `has_reviewed` / `review_state` fields on each reviewer item; the extra API call is gated behind the toggle so existing graphs are unaffected - Refactor: hoist `GITHUB_API_URL` constant into `_api.py` and reuse it ### Checklist 📋 #### For code changes: - [x] I have clearly listed my changes in the PR description - [x] I have made a test plan - [x] I have tested my changes according to the test plan: - [x] `poetry run pytest backend/blocks/test/test_block.py` — full block suite passes, including schema validation + mocked execution of all new/changed blocks - [x] `poetry run pytest backend/blocks/github/test_github_blocks.py` — passes - [ ] Live-run the List / Mark as read blocks against a real GitHub account (not done — mocked execution only) <details> <summary>Example test plan</summary> - [ ] Create from scratch and execute an agent with at least 3 blocks - [ ] Import an agent from file upload, and confirm it executes correctly - [ ] Upload agent to marketplace - [ ] Import an agent from marketplace and confirm it executes correctly - [ ] Edit an agent from monitor, and confirm it executes correctly </details> #### For configuration changes: - [x] `.env.default` is updated or already compatible with my changes - [x] `docker-compose.yml` is updated or already compatible with my changes - [x] I have included a list of my configuration changes in the PR description (under **Changes**) <details> <summary>Examples of configuration changes</summary> - Changing ports - Adding new services that need to communicate with each other - Secrets or environment variable changes - New or infrastructure changes such as databases </details> --------- Co-authored-by: Claude Fable 5 <[email protected]>
3.9 KiB
GitHub Commits
Blocks for listing commit history and creating multi-file commits in GitHub repositories.
Github List Commits
What it is
This block lists commits on a branch in a GitHub repository.
How it works
This block fetches commits from a GitHub repository using the Commits API. You can filter by branch name and control the number of results with pagination parameters.
Each commit entry includes the SHA, commit message, author name, date, and a URL to view the commit on GitHub.
Inputs
| Input | Description | Type | Required |
|---|---|---|---|
| repo_url | URL of the GitHub repository | str | Yes |
| branch | Branch name to list commits from | str | No |
| limit | Maximum number of commits to fetch | int | No |
| per_page | [Legacy] Number of commits to return per page (max 100). If set (or page is set), limit is ignored. |
int | No |
| page | [Legacy] Page number for pagination. If set (or per_page is set), limit is ignored. |
int | No |
| path | Only include commits that touch this file or directory path | str | No |
| author | Only include commits authored by this user (GitHub username or email address) | str | No |
| committer | Only include commits committed by this user (GitHub username or email address) | str | No |
| since | Only include commits after the given ISO 8601 timestamp | str | No |
| until | Only include commits before the given ISO 8601 timestamp | str | No |
Outputs
| Output | Description | Type |
|---|---|---|
| error | Error message if listing commits failed | str |
| commit | A commit with its details | Commit |
| commits | List of commits with their details | List[CommitItem] |
Possible use case
Activity Monitoring: Track recent commits on a branch to monitor development progress.
Changelog Generation: Retrieve commit messages to automatically compile release notes or changelogs.
Audit Trail: List commits to review who made changes and when for compliance purposes.
Github Multi File Commit
What it is
This block creates a single commit with multiple file upsert/delete operations using the Git Trees API.
How it works
This block creates a single atomic commit that can add, update, or delete multiple files at once using the low-level Git Trees API. It fetches the latest commit SHA on the target branch, creates blobs for each upserted file concurrently, builds a new tree with all file operations, creates a commit pointing to that tree, and updates the branch reference.
For delete operations, a null SHA is set in the tree entry to remove the file. This approach is more efficient than making separate commits per file and ensures all changes land in a single commit.
Inputs
| Input | Description | Type | Required |
|---|---|---|---|
| repo_url | URL of the GitHub repository | str | Yes |
| branch | Branch to commit to | str | Yes |
| commit_message | Commit message | str | Yes |
| files | List of file operations. Each item has: 'path' (file path), 'content' (file content, ignored for delete), 'operation' (upsert/delete) | List[FileOperationInput] | Yes |
Outputs
| Output | Description | Type |
|---|---|---|
| error | Error message if the commit failed | str |
| sha | SHA of the new commit | str |
| url | URL of the new commit | str |
Possible use case
Automated Code Generation: Commit generated code, configuration files, and scaffolding in a single atomic operation.
Batch File Updates: Update multiple configuration or documentation files across a repository in one commit.
Cleanup Operations: Delete obsolete files while adding replacements in a single commit to keep history clean.