mirror of
https://github.com/Significant-Gravitas/AutoGPT.git
synced 2026-11-10 17:48:43 -10:00
dev
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Nicholas TindleandClaude Opus 5.5
|
f90049a17a |
feat(blocks): add GitHub repository traffic block (views, clones, referrers, popular content) (#15188)
### Why / What / How
**Why:** Agents and AutoPilot can't answer "how many views and clones
did we get?". GitHub's official MCP server, which is in our catalog, has
no traffic tools; there's an open request for them
(github/github-mcp-server#3164). The nightly `github-repo-stats`
workflow was removed in #15169 (an internal collector now archives the
org's own repos), so nothing on the platform reads traffic for a user's
repository. It's on the growth and marketing analytics wish list, next
to PostHog (already in the MCP catalog), Hacker News, Google Analytics
and Search Console.
**What:** One read-only block in the GitHub family, Github Get
Repository Traffic. One run returns what a repository's Insights >
Traffic page shows.
**How:**
- Calls the four traffic endpoints at the same time (`asyncio.gather`)
through the existing `get_api`:
- `GET /repos/{owner}/{repo}/traffic/views?per=day|week`
- `GET /repos/{owner}/{repo}/traffic/clones?per=day|week`
- `GET /repos/{owner}/{repo}/traffic/popular/referrers` (top 10)
- `GET /repos/{owner}/{repo}/traffic/popular/paths` (top 10)
- **Inputs:** GitHub credentials (`repo` scope), `repo_url` (a
github.com link or `owner/repo`, checked by `normalize_repo_path`) and
`period` (`day` by default, or `week`).
- **Outputs:** `views`, `unique_visitors`, `views_by_period`, `clones`,
`unique_cloners`, `clones_by_period`, `referrers` and `popular_content`,
named after the Traffic page's labels. Each popular page also gets its
github.com `url`. Lists only, no per-item outputs: they are short and
read whole.
- **Errors:**
- A 403 saying the caller can't read traffic ("Must have push access to
repository", or "Resource not accessible by ..." for a fine-grained
token) becomes: "GitHub only shows traffic to people with push access to
owner/repo. Connect a GitHub account that can push to it; a fine-grained
token also needs the Administration (read) permission."
- A 404 says the repository wasn't found or the account can't see it.
- Other 403s (rate limits, SAML SSO, IP allow lists) and 401s keep
GitHub's message. A 401 reaches AutoPilot unchanged, so its reconnect
prompt still works.
- An invalid repository is a `BlockInputError`, raised before any
request.
- **Conventions:** each request is a static method the self-test mocks.
`run()` does the gather, error mapping and parsing, so the self-test
parses realistic payloads. `run()` isn't wrapped in a broad
`try/except`. Effect is `READ`, so AutoPilot runs it without asking.
Categories: Developer Tools and Marketing.
### Changes 🏗️
- `backend/blocks/github/traffic.py`: `GithubGetRepositoryTrafficBlock`
(`aa46e092-b04f-492a-ae13-bb920f1469c2`) and its `TrafficCount`,
`TrafficReferrer` and `PopularContent` output types.
- `backend/blocks/github/traffic_test.py` (29 tests) and
`traffic_effects_test.py` (pins `BlockEffect.READ`).
- Docs: `docs/integrations/block-integrations/github/traffic.md`, plus
the generated `README.md` and `SUMMARY.md` entries.
- No existing blocks, settings or env vars change.
- **What users need:** push (write) access to the repository. The GitHub
connection or a classic token needs the `repo` scope; a fine-grained
token needs the Administration repository permission (read). GitHub
keeps 14 days, so the docs suggest a daily run that appends to a Google
Sheet for longer history.
### Agents and large language models used
- Claude Code with Claude Opus 5.5
### 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] Block self-test passes via `execute_block_test`, and
`test_block.py -k GithubGetRepositoryTraffic --noconftest` gives 6
passed (self-test, effect checks, uuid4 id)
- [x] New and existing GitHub tests: 160 passed (`traffic_test.py`,
`traffic_effects_test.py`, `test_github_blocks.py`, `--noconftest`). The
new ones cover:
- URLs and the `per` parameter for each endpoint, and `get_api` built
with `convert_urls=False`
- all four requests in flight at once
- URL and `owner/repo` input, and invalid repositories and periods
rejected before any request
- parsing realistic, empty, missing and null fields, and page links
- error mapping: no push access, fine-grained token, 404, rate limit,
401
- [x] `test_block.py -k "declares_an_effect or ids_valid or effect_none
or irreversible" --noconftest`: 3037 passed, 83 skipped
- [x] `copilot/capabilities/registry_test.py` and
`integrations/provider_logos_test.py`: 146 passed. The copilot listing
is 297 characters, and copilot search ranks the block first for "how
many clones did our github repo get".
- [x] `ruff`, `isort` and `black` clean over the whole backend;
`pyright` 0 errors
- [x] `load_all_blocks()` loads all 624 blocks; `generate_block_docs.py
--check` reports all documentation in sync
- [x] Ran the block itself against GitHub with a real token that can
push to Significant-Gravitas/AutoGPT, weekly breakdown: 40,434 views
(19,507 unique visitors), 186,288 clones (8,347 unique cloners), two
weekly buckets each, 10 referrers and 10 pages with their links. Both
`owner/repo` and a github.com URL worked.
- [x] Errors from the same live run: `torvalds/linux` (no push access)
gave the push-access message, a repository that doesn't exist gave the
not-found message, and `not a repo` was rejected before any request.
- [ ] `test_block.py` against the Docker test stack (not run; the runs
above use `--noconftest`)
**Not verified:**
- The fine-grained token 403 wording ("Resource not accessible by
personal access token") is GitHub's usual message for a missing
permission. I didn't see it from this endpoint.
- In the live check the newest daily entry was yesterday (UTC). I don't
know whether GitHub ever includes the current, partial day.
#### For configuration changes:
- [x] `.env.default` is updated or already compatible with my changes
(no new settings)
- [x] `docker-compose.yml` is updated or already compatible with my
changes (no changes)
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**). There are none.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Additive read-only integration with isolated new code and tests; no
auth, persistence, or existing block behavior changes.
>
> **Overview**
> Adds a **read-only** GitHub block, **Github Get Repository Traffic**,
so workflows can pull the same metrics as **Insights → Traffic** (14-day
views/clones, referrers, popular paths).
>
> One run **fans out four REST calls in parallel** (`views`, `clones`,
`popular/referrers`, `popular/paths`) via the existing `get_api` helper
(`convert_urls=False`). Inputs are `repo_url` (normalized with
`normalize_repo_path`), optional `period` (`day`/`week` for
views/clones), and repo-scoped credentials. Outputs aggregate totals,
per-period breakdowns, top referrers, and popular pages with built
`github.com` URLs.
>
> **Error handling** maps traffic-specific 403s and 404s to clearer
`BlockExecutionError` messages; rate limits and 401s are left for
AutoPilot. The block declares **`BlockEffect.READ`** (Developer Tools +
Marketing categories).
>
> Also adds **unit/effect tests** and integration docs (`traffic.md`,
index entries in `README.md` / `SUMMARY.md`). No changes to existing
blocks or configuration.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
|
||
|
Reinier van der LeerandClaude Sonnet 5
|
775039b297 |
feat(blocks): output full PR object from GithubReadPullRequestBlock (#14295)
## Summary This PR adds a new `pull_request` output to `GithubReadPullRequestBlock` that carries the full, raw pull request object returned by the GitHub API — including head/base refs (with fork repo and branch name for cross-repo PRs), mergeability, and draft state — without touching any of the block's existing outputs. ### Why / What / How **Why:** The block's existing outputs (`title`, `body`, `author`, `changes`) don't expose fork/branch info, mergeability, or draft state. [OPEN-2780](https://github.com/Significant-Gravitas/AutoGPT/issues/11115) specifically asked for the PR's fork URL and branch name; rather than whitelist just those two fields, this exposes the whole object so any future need (draft state, review counts, labels, etc.) is covered without another block change. **What:** Adds a `pull_request: dict` output field with a description documenting its contents, and yields the raw PR JSON alongside the existing outputs. Nothing else in the block's input/output schema changes. **How:** `GithubReadPullRequestBlock.read_pr` fetches from the `/issues/{n}` endpoint (title/body/author only — it omits head/base/mergeability). The new `read_pr_full_object` static method fetches `/pulls/{n}` directly, which is the endpoint that actually carries the full object, and returns the response body unmodified. This follows the precedent set by `GithubGetUserInfoBlock.user` in [#13634](https://github.com/Significant-Gravitas/AutoGPT/pull/13634): yield the raw API object with a descriptive `SchemaField`, rather than hand-picking fields. ### Changes 🏗️ - `GithubReadPullRequestBlock`: new `pull_request` output (raw PR object from `GET /pulls/{n}`); new `read_pr_full_object` static method; existing `title`/`body`/`author`/`changes` outputs and their behavior are unchanged. - Regenerated block docs (`docs/integrations/`) to reflect the new output. Resolves [#11115](https://github.com/Significant-Gravitas/AutoGPT/issues/11115) ### 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] Extended `backend/blocks/github/test_github_blocks.py` with unit tests for `read_pr_full_object` (hits the `/pulls/{n}` endpoint, not `/issues/{n}`; returns the raw response body) — ran, pass. - [x] Ran the full `backend/blocks/github/test_github_blocks.py` suite (127 tests) — pass. - [x] Ran `test_available_blocks[GithubReadPullRequestBlock]` (the generic block-schema/test_output/test_mock harness) — pass. - [x] Ran `generate_block_docs.py --check` before and after regenerating — confirms it was out of sync, confirms a second run is idempotent, confirms `--check` now exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 5 <[email protected]> |
||
|
Reinier van der LeerandClaude Fable 5
|
5e548164e1 |
feat(blocks): Add GitHub notification management blocks (#13634)
### 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]> |
||
|
Zamil Majdy
|
9f4caa7dfc |
feat(blocks): add and harden GitHub blocks for full-cycle development (#12334)
## Summary - Add 8 new GitHub blocks: GetRepositoryInfo, ForkRepository, ListCommits, SearchCode, CompareBranches, GetRepositoryTree, MultiFileCommit, MergePullRequest - Split `repo.py` (2094 lines, 19 blocks) into domain-specific modules: `repo.py`, `repo_branches.py`, `repo_files.py`, `commits.py` - Concurrent blob creation via `asyncio.gather()` in MultiFileCommit - URL-encode branch/ref params via `urllib.parse.quote()` for defense-in-depth - Step-level error handling in MultiFileCommit ref update with recovery SHA - Collapse FileOperation CREATE/UPDATE into UPSERT (Git Trees API treats them identically) - Add `ge=1, le=100` constraints on per_page SchemaFields - Preserve URL scheme in `prepare_pr_api_url` - Handle null commit authors gracefully in ListCommits - Add unit tests for `prepare_pr_api_url`, error-path tests for MergePR/MultiFileCommit, FileOperation enum validation tests ## Test plan - [ ] Block tests pass for all 19 GitHub blocks (CI: `test_available_blocks`) - [ ] New test file `test_github_blocks.py` passes (prepare_pr_api_url, error paths, enum) - [ ] `check-docs-sync` passes with regenerated docs - [ ] pyright/ruff clean on all changed files |
||
|
|
90466908a8 |
refactor(docs): restructure platform docs for GitBook and remove MkDo… (#11825)
<!-- Clearly explain the need for these changes: -->
we met some reality when merging into the docs site but this fixes it
### Changes 🏗️
updates paths, adds some guides
<!-- Concisely describe all of the changes made in this pull request:
-->
update to match reality
### 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:
<!-- Put your test plan here: -->
- [x] deploy it and validate
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Aligns block integrations documentation with GitBook.
>
> - Changes generator default output to
`docs/integrations/block-integrations` and writes overview `README.md`
and `SUMMARY.md` at `docs/integrations/`
> - Adds GitBook frontmatter and hint syntax to overview; prefixes block
links with `block-integrations/`
> - Introduces `generate_summary_md` to build GitBook navigation
(including optional `guides/`)
> - Preserves per-block manual sections and adds optional `extras` +
file-level `additional_content`
> - Updates sync checker to validate parent `README.md` and `SUMMARY.md`
> - Rewrites `docs/integrations/README.md` with GitBook frontmatter and
updated links; adds `docs/integrations/SUMMARY.md`
> - Adds new guides: `guides/llm-providers.md`,
`guides/voice-providers.md`
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
|