mirror of
https://github.com/Significant-Gravitas/AutoGPT.git
synced 2026-11-09 04:49:50 -10:00
dev
22
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Nicholas TindleandClaude Opus 5.5
|
cb690ed9cc |
ci(platform): let the credits PR run CI and flag advisories no release lists (#16259)
### Why / What / How **Why:** two gaps in the public security sync from #16151. 1. **The credits PR's CI never starts by itself.** The sync opens its credits PR with `GITHUB_TOKEN`. In this repo, every CI run on a PR opened that way waits as `action_required` until a maintainer approves it. #13152, the weekly Anthropic-rates PR, has sat like that since May. So each credits update would need that click before it could even be reviewed. 2. **A forgotten release link goes unnoticed.** An advisory is listed under a release only when its description links that release. A published advisory without the link is left out of every release's notes, with no warning anywhere. **What:** the credits PR is opened by the batch-bot App, so its CI runs like any other PR's. The dry-run summary and the credits PR both name any published advisory that no release lists. **How:** - The credits job mints a batch-bot App token with `actions/create-github-app-token`, scoped to `contents: write` and `pull-requests: write`, the same way `docs-gitbook-sync.yml` does. It mints the token after the files are generated and passes it only to the `create-pull-request` step. The job's own `GITHUB_TOKEN` now has no permissions. - The release writer keeps `GITHUB_TOKEN` on purpose. Release edits made with it never start release workflows, which is what keeps old tags' `release.edited` image builds from firing. - A new `unlinked_advisories(snapshot)` helper returns the published advisories with no release tags. The `credits` command's JSON output carries that list, the credits PR body lists it, and the preview prints it ("none." today). ### Changes 🏗️ - `.github/workflows/security-advisory-sync.yml` (credits job): - The PR token is a batch-bot App token, and the job's own `GITHUB_TOKEN` has no permissions. - The PR body gets a line listing unlinked advisories. - The checklist no longer asks the maintainer to approve CI runs. - `security_public_sync.py`: adds `unlinked_advisories()`; `prepare_credits()` returns it under `unlinked`. - `security_public_publish.py`: the preview names unlinked published advisories, or says none. - `test_security_public_sync.py`: a new test covers the list in the credits output and the preview, including that drafts never appear. The exact-output assertions now include `unlinked`. - `docs/engineering/security-advisory-release-notes.md`: the permissions paragraph explains why each writer uses the token it does, and rollout step 4 and the read-only job's description are updated. ### Agents and large language models used - Claude Code with Claude Opus 5.5: design, implementation and validation. ### 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] `python -m unittest discover -s .github/workflows/scripts -p 'test_*.py'`: 101 passed. The security tests also pass on Python 3.10, which "Check PR Status" uses. - [x] Three mutants are each killed by the new test: the inverted filter, the list dropped from the credits output, and the preview always saying none. - [x] Live anonymous dry run against the public API: `credits` reports `"unlinked": []`, and the preview still proposes sections for 19 releases and reports no unlinked advisories. - [x] `actionlint` 1.7.12 is clean on the three security and Classic workflows. The new step's `jq` expression and `errexit` handling were exercised with both empty and non-empty lists and a failing `credits` command. - [x] `pre-commit` (Black, gitleaks, merge-conflict and debug checks) on the changed files. - [ ] Live App-token PR creation: this runs only after the variables are enabled on `master`. The batch-bot App already opens and updates PRs here (`batch-command-handler.yml` uses `permission-pull-requests: write`). #### 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**). It uses the existing `BATCH_BOT_APP_ID` variable and `BATCH_BOT_PRIVATE_KEY` secret; nothing new. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 (Claude Code) <[email protected]> |
||
|
|
9fffbaf537 |
ci(platform): sync public security credits and release notes (#16151)
### Why / What / How **Why:** our public researcher credits and each release's security notes drift from the published advisories. Advisories get published after the release that fixed them, credits get accepted later, and records get corrected or withdrawn. `SECURITY.md`'s list was last edited by hand in September, and no release note links its advisories. Separately, the Classic Docker release job runs on every Platform release. Its `startsWith(github.ref, 'refs/tags/autogpt-')` filter matches `autogpt-platform-beta-v*`, so it has started on every Platform release since at least v0.6.69, and again whenever a maintainer edits release notes (`types: [published, edited]`; v0.7.1 and v0.7.4 each ran twice). Every run failed only because `Dockerfile.autogpt` no longer exists. A successful build would have pushed `significantgravitas/auto-gpt:latest` plus a Platform-numbered tag over the Classic image. **What:** a scheduled sync that keeps the `SECURITY.md` acknowledgments and a "Security fixes" section in each release's notes in step with the published advisories. It also limits the Classic Docker release job to published Classic tags. **How:** the sync never has access to private reports. - It reads advisories anonymously and keeps four identifier fields per advisory in a committed public snapshot: GHSA ID, CVE ID, accepted researcher handles and release tags. - A read-only job validates the data and previews the exact sections a run would write. - Two writers are each off until their own variable is set: one opens a credits PR against `dev`, the other edits only the managed block of existing releases. - Both writers run pinned `master` code, re-fetch the public data and stop if it changed since the read-only job. ### Changes 🏗️ - **Security sync** (`.github/workflows/security-advisory-sync.yml`, every six hours, plus a manual dry run). Scripts: - `security_public_api.py`: anonymous, bounded HTTPS reads. No auth, proxy or redirects. Failures log only a fixed reason. - `security_public_sync.py`: the four-field projection, the generated `SECURITY.md` block and the release section. - `security_public_publish.py`: preview, or the release-body update. - `security_release_notes.py`: credit consent and the release each advisory was fixed in. - **Release matching:** an advisory is listed under a release when its description links that release's tag URL *and* one of its package rows gives that release's version as patched. A hidden `security-release` mapping is needed only when the rows report different patched versions. - **Release writer:** preserves every note outside the managed block, from a fresh read. It sends `make_latest` on every edit: `true` for the current Latest release, `false` for the rest. It also checks `releases/latest` before the first edit and after the last. - **`SECURITY.md`:** - Generated credits, keeping each researcher's chosen name beside their handle where they gave one. - No team members and no stale per-person counts. - The one acknowledgment with no published advisory credit is kept as historical. - **Classic Docker release workflow:** `types: [published]`, a `refs/tags/autogpt-v` filter and `permissions: contents: read`. - **CI:** `security-advisory-sync-test.yml` runs the tests against the PR head. The required "Check PR Status" job runs them only from the base commit. - **Runbook:** `docs/engineering/security-advisory-release-notes.md` covers rollout, duplicate consolidation and Docker package metadata. **Takeover changes (since `0fdc05b`):** - Advisories whose package rows agree on the fixed version are now matched to their release. Before, an advisory with a Platform row and a Docker image row, both patched in `0.9.0`, made the projection raise `RELEASE_MAPPING`. The reader job runs that projection, so publishing one advisory in that format would have stopped every run until someone added hidden comments by hand. - The release writer now keeps the current Latest release. GitHub documents `make_latest` as defaulting to `true` on updates. The first run edits 19 older releases, newest first and ending on v0.4.3, while v0.9.0 is Latest. - Removed the manual release-note helper. It was a second writer for the same block (with titles), and the next scheduled run would have replaced its output. Its tests now drive the automated path. - Restored the chosen names of 16 researchers, such as "Joshua Rogers (`@MegaManSec`)", and left the team's handles out of the acknowledgments (`TEAM_LOGINS`). `SECURITY.md` and the snapshot are regenerated from live public data. - Dropped the mention of a `PUBLIC_SECURITY_SYNC_ENABLED` switch that `dev` never had, and merged `dev`. **Rollout:** 1. Merge through `dev` to `master` with both writer variables unset. 2. Dispatch a dry run and review the job summary. 3. Set `PUBLIC_SECURITY_CREDITS_ENABLED=true`. CI on the PR it opens waits for a maintainer to approve the workflow runs, as it does on other `GITHUB_TOKEN`-created PRs here. 4. After reviewing the preview, set `PUBLIC_SECURITY_RELEASE_NOTES_ENABLED=true`. A manual release-note edit made during the writer's run can still be overwritten, because GitHub has no conditional PATCH for releases. The guide says so. ### Agents and large language models used - Codex with GPT-6 Astra: the original implementation and its review rounds. - Claude Code with Claude Opus 5.5: the takeover design review, the changes listed under "Takeover changes", and the validation below. ### 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] `python -m unittest discover -s .github/workflows/scripts -p 'test_*.py'`: 98 passed on Python 3.11. The security tests also pass on Python 3.10, which the required "Check PR Status" job uses. - [x] Reproduced the two-row failure with the PR's own `public_snapshot` before the fix (`RELEASE_MAPPING`); passes after. - [x] 11 mutants of the new code, each killed by its own failing assertions: - the two-row rule; - `make_latest` in the payload; - which release claims Latest; - the Latest pre-read and post-check; - the team filter and its case-insensitive match; - name rendering. - [x] Live anonymous run against the public API: - `digest` and `credits` regenerate the committed `SECURITY.md` and snapshot byte for byte. - `--preview` proposes sections for 19 releases, with the chosen names and no team handles. - The current Latest release is v0.9.0. - [x] `pre-commit` (Black, gitleaks, merge-conflict and debug checks) on the changed files. - [ ] Live write path during rollout: no variables set and no release edited during development. #### 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**): two repository variables, both unset by default. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: GPT-6 Astra (Codex) <[email protected]> Co-authored-by: Claude Opus 5.5 (Claude Code) <[email protected]> |
||
|
Nicholas TindleandClaude Opus 5.5
|
c52ce5d6cf |
fix(platform): refresh Debian packages in image builds daily so security fixes ship (#15464)
### Why / What / How **Why:** The single-container image check on `dev` fails its Trivy scan with `trivy-critical.json contains findings: Vulnerabilities=4`: Debian `chromium` and `chromium-common` 154.0.8037.92-1~deb13u1 (CVE-2026-106195, CVE-2026-106237), fixed in 155.0.8059.39-1~deb13u1, which trixie-security already serves for amd64 and arm64. The fix never reaches the image: `backend/Dockerfile` installs Chromium in an apt layer, and the build cache keeps reusing that layer (`#46 CACHED` on the Chromium step in the failing runs), so the image ships the old Chromium until something above the layer changes. Because the check fails, "Check PR Status" fails for every PR touching the Dockerfiles, the lockfiles or the single-container files, and they can't enter the merge queue. The prod, dev and preview images are built from the same Dockerfile with layer caches too, so they carry the same stale Chromium: the browser the Copilot browser tool drives against arbitrary websites. **What:** A build argument, `APT_REFRESH`, declared right before the package installs of every stage that installs Debian packages. Every CI build of these images passes the UTC date. **How:** BuildKit adds a declared build argument's value to the environment of every later `RUN` in the stage, which makes it part of those steps' cache keys. A new date re-runs the stage's package installs and whatever follows them in that stage; the steps before them, and stages without package installs (the frontend build among them), keep hitting the cache. The date changes once a day, so OS packages are at most a day behind Debian. A build that doesn't pass the argument, such as a local `docker compose build`, gets an ARG with no value, which adds nothing to the environment, so its cache keys stay as they are. ### Changes 🏗️ - `autogpt_platform/backend/Dockerfile`: `ARG APT_REFRESH` before the first package install of `builder` (its Node.js package is copied into the migrate and server images), `migrate`, and `server-base` (which installs Chromium). - `autogpt_platform/single-container/Dockerfile`: `ARG APT_REFRESH` before the appliance stage's package install (PGDG PostgreSQL, nginx, Valkey, ...). The comment on the per-build arguments at the end now names just those. - `platform-single-container-docker.yml`: a step sets the date (`date -u +%F`), and both bake builds (CI and release) pass it as `*.args.APT_REFRESH`, which reaches the linked backend targets as well. `single_container_cache.py` needs no change: dev pushes still write the shared `v4-<arch>` registry cache, so the first build of a day re-runs the package layers and its export hands them to that day's PR builds. - `platform-fullstack-ci.yml`: the backend bake passes the date, so E2E runs against the packages that ship. - `copilot-setup-steps.yml`: the migrate build passes the date. - Tests: `test_dockerfile_layers.py` checks that every stage with a package install declares `APT_REFRESH` before its first install, that the Chromium install follows it, and that every bake build in the single-container workflow passes the date from an earlier step. The existing "build arguments follow every layer" test exempts `APT_REFRESH`, which belongs before the package layers. `test_e2e_seed_cache_contract.py` checks that the full-stack backend bake passes it. - Separate commit: black formatting that was already due in `check_actions_status.py`, its test, and `test_frontend_environment.py`. #15449 carries the same formatting and merges with this cleanly. - Companion infra PR passes the same argument in the prod, dev and preview backend image builds: Significant-Gravitas/AutoGPT_cloud_infrastructure#444 ### 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] `autogpt_platform/single-container/tests`: new and existing tests pass. The two `test_ci_smoke_stop` subtests fail locally under macOS's `/bin/bash` 3.2, the same as on `dev`; CI runs them on Linux. - [x] Removing `APT_REFRESH` from any of the four stages, from the release bake, or removing the date step fails the matching test - [x] `.github/scripts/test_e2e_seed_cache_contract.py` and the `.github/workflows/scripts` tests pass - [x] `docker buildx build --check` on both Dockerfiles reports no warnings; actionlint reports nothing new - [ ] This PR's "Build, smoke, and scan" jobs re-run the package layers and the Trivy critical scan passes on amd64 and arm64 #### 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**) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <[email protected]> |
||
|
Nicholas TindleandClaude Opus 5.5
|
e09793064a |
ci(platform): add a journeys leg to e2e for hosted-config user journeys (#15397)
### Why / What / How
**Why:** CI's e2e job tests a different product from the one customers
use. It runs every flag at its code default (off), with credits
disabled, and the 30 smoke specs check that pages render, not that flows
work. The stability-patrol bug archaeology found ~123 of 300 recent
user-facing bugs would have been caught by a holistic browser journey,
about half of them only with hosted-like configuration. Fix PRs almost
never add one, because there's nowhere cheap to put it.
**What:** A second leg of the e2e job that runs `*-journey.spec.ts`
against the hosted configuration on its own runner, plus the conventions
and the first journey. Other patrol agents are adding schedules,
realtime-after-reconnect and session journeys on top of this.
**How:**
- `e2e_test` becomes a `smoke` / `journeys` matrix with `fail-fast:
false`. Each leg has its own runner, so wall clock is `max(leg)`, not
the sum.
- The smoke leg is unchanged. Only smoke writes the shared caches (GHCR
build cache, Next.js cache, Playwright browsers).
- The journeys leg skips the OpenAI key, so its seed runs ~30 s instead
of ~3 min, and it gets its own seed-cache key (`emb`/`noemb`).
- **Journeys are advisory for now:** `end-to-end tests (journeys)` is in
`ADVISORY_CHECK_RUNS`. We flip it to blocking once it has proven stable.
- **Hosted configuration.** One file,
`src/playwright/journeys/hosted-flags.json`, holds the flags production
serves on for everyone.
- Backend: `.github/scripts/hosted_journeys_env.py` turns it into
per-flag `FORCE_FLAG_*` lines, plus `ENABLE_CREDIT=true` (not
`FORCE_ALL_FLAGS`).
- Frontend: Playwright builds (`NEXT_PUBLIC_PW_TEST=true`) now read flag
values from local storage, which the journey fixtures set before the app
loads. I deliberately didn't use build-time `NEXT_PUBLIC_FORCE_FLAG_*`:
a differently-flagged bundle can't reuse the smoke leg's cached image.
That means a cold 450–600 s Next build on every run, which would make
the journeys leg finish after smoke on frontend-cached runs. Production
builds never read the override.
- `enable-platform-payment` is forced **off**, because journey users
have no subscription and would hit the 402 paywall.
- `EXECUTION_COST_COUNT_THRESHOLD=1` bills every node, so a run's cost
is visible and exactly assertable. This is a deliberate deviation from
hosted.
- **Journey fixtures** (`src/playwright/journeys/fixtures.ts`):
- `journeyUser` signs up a fresh user through the auth API and completes
onboarding, which grants the onboarding credits. It works against any
`PLAYWRIGHT_BASE_URL`, including a `!deploy` preview, and never uses
CI's seeded accounts.
- An automatic **guard** fails a journey on any unexpected `/api/*`
4xx/5xx, `pageerror` or `console.error`, printing the URL, status and a
body snippet. Journeys declare deliberate errors with `test.use({
expectedResponses })`. Known noise goes in a small reviewed allowlist
(`KNOWN_BENIGN`, with reasons).
- **First journey** (`run-correctness-journey.spec.ts`, archaeology J4).
Import a small agent through the Library UI, run it, and assert:
- the run reaches COMPLETED and its output shows in the run view;
- the Library run list shows the run;
- the credit ledger charged the run exactly its cost, and the balance
moved by exactly the new ledger entries;
- a run with a failing node ends FAILED (not stuck RUNNING/QUEUED) and
its error is shown.
### Changes 🏗️
- `.github/workflows/platform-fullstack-ci.yml`: the matrix, per-leg
seed cache, cache writes and artifacts (`playwright-report-<suite>`,
`playwright-test-results-<suite>`), `--min-tests ${{ matrix.min_tests
}}` (smoke 28, journeys 3), and Codecov `name: e2e-<suite>`.
- `.github/scripts/validate_playwright_json.py`: new opt-in
`--allow-known-failures`, used only by the journeys leg. A `test.fail()`
known failure is accepted only if it actually failed; smoke stays
strict.
- `.github/workflows/scripts/check_actions_status.py`: the journeys
check is advisory. Adds a test.
- `.github/scripts/hosted_journeys_env.py` and its test; contract tests
updated for the matrix.
- `autogpt_platform/frontend/playwright.journeys.config.ts`
- `src/playwright/journeys/`: `fixtures.ts`, `guard.ts`,
`journey-user.ts`, `credits.ts`, `hosted-flags.json`, `README.md`
(conventions; how to run locally, against a preview and in CI; open
hosted vs self-hosted gaps), and the first journey.
- `src/services/feature-flags/pw-flag-overrides.ts` and
`use-get-flag.ts`: the runtime flag override for Playwright builds, with
unit tests.
- `TaskListItem` / `SidebarItemCard`: a `data-testid` on Library run
items.
**Configuration changes:** none for self-hosters or hosted. The journeys
leg appends `ENABLE_CREDIT=true`, `EXECUTION_COST_COUNT_THRESHOLD=1` and
`FORCE_FLAG_*` to its own CI `backend/.env`.
**Not done here (follow-ups):**
- Scaling `executor`/`copilot_executor` to 2 needs their fixed host
ports (8002/8008) removed in a compose override. Then we'd need to check
that the executor RPC tolerates replicas.
- No scripted model server (W9); chat stays on `CHAT_TEST_MODE`.
**Coordination:** no overlap with #15225 (single-container cache),
#15231 (`login.page.ts`, which journeys don't use) or #15352 (copilot
unit tests).
### Agents and large language models used
Claude Code — 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
- [ ] I have tested my changes according to the test plan:
- [x] `.github/scripts` validator and contract tests, and
`check_actions_status` tests, pass locally
- [x] Feature-flag unit tests pass (97), including the new override
tests
- [x] Journeys leg passes in this PR's CI (run 38171220939): 3 tests,
validator reports "3 tests passed once without skips or retries"
- [x] Smoke leg unchanged: 28+ tests, green in every run of this PR
- [x] Journeys pass locally on the patrol stack too (3 passed, one of
them the expected known failure)
- [x] Wall clock: the journeys leg finished before smoke in every run
(frontend rebuilt in all of them, since this PR touches the frontend):
| Run | journeys leg | smoke leg | journeys Playwright step |
|---|---|---|---|
| 38166219280 | 11m31s (failed: spec bug) | 16m49s | 113 s |
| 38168727001 | 12m00s (failed: findings below) | 19m37s | ~80 s |
| 38171220939 | **10m02s ✅** | **14m40s ✅** | 71 s |
Without embeddings the journeys seed took 62–93 s; with embeddings,
smoke's takes ~3 min.
### Findings from the first journey (on `dev`, not caused by this PR)
1. **A run whose node fails reports COMPLETED, and the user never sees
the error.** A MatchTextPattern node raises `Invalid regex pattern` with
nothing wired to its error output. The run view then shows "Completed"
and "No output from this run.", and nothing else. Untyped node errors
are non-fatal by design (`backend/executor/manager.py`, the final-status
block). This is the open product question of #14275 / SECRT-2840, so the
journey pins it with `test.fail()`: it goes red the day the behavior
changes, and then the marker comes off. A separate journey checks that
such a run at least *ends* (passes).
2. **A brand-new user's first page 404s on `GET /api/store/profile`**
("User does not have a profile yet"). The profile is only created by
`POST /api/auth/user`, which the app fires on load in parallel with the
navbar's profile query. The guard caught it in 1 of 3 tests. Journey
users now finish account setup first. A first-login journey should
assert this and fail until it's fixed.
3. `importAgentFromFile` in `pages/library.page.ts` returns an empty
`seeRunsUrl`/`id`, because "See tasks" on the Library card is now a
button, not a link. The journey looks the agent up through the API
instead. The page object should get the same fix.
#### 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**)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5.5 (Claude Code) <[email protected]>
|
||
|
Nicholas Tindleandunknown
|
28d65d4a21 |
ci(platform): keep the gitbook branch a one-way copy of master's docs (#15165)
### Why / What / How
**Why:** GitBook publishes agpt.co/docs from the `gitbook` branch. That
branch has been kept in step with `dev` by hand-made sync PRs (#14019,
#14171, #14554), and it drifts between them: the live site is currently
three weeks behind. The branch is also writable by people and by GitBook
itself, so changes could be made there that never reach `dev`. The
branch exists so that GitBook never writes to a deployable branch; that
stays.
**What:** `gitbook` becomes a one-way, docs-only copy of `master`'s
`docs/`, written only by automation. The published docs then match what
is deployed. If anything else writes to the branch, the sync reports it
in an issue and puts `master`'s docs back.
**How:** A workflow runs on every push to `master`, daily, and on manual
dispatch. It runs a small stdlib-only script as the `autogpt-batch-bot`
App. The script reads `master`'s `docs/` tree, and if `gitbook` does not
already hold exactly that, writes one commit on top of the branch head
whose tree is only `docs/`. It uses the Git Data API, never
force-pushes, and leaves author and committer unset so GitHub signs the
commit as the App. A repository ruleset (applied by hand afterwards,
recorded here as JSON) restricts updates of `gitbook` to that App.
`GITHUB_TOKEN` cannot be given a ruleset bypass, which is why the App is
used.
### Changes 🏗️
- **`.github/workflows/docs-gitbook-sync.yml`** (new): the workflow. It
only runs in this repository and only from `master`'s copy of itself.
- **`.github/workflows/scripts/gitbook_sync.py`** (new): the sync.
- A commit it wrote carries a `Synced-From: <master sha>` trailer. The
head counts as its own only if it is docs-only and its `docs/` equals
that commit's `docs/`.
- When the head is not its own, it lists the first-parent commits since
its last snapshot and who moved the branch (repository activity log),
reports them in an issue **before** moving the branch, writes a fresh
snapshot on top, and exits non-zero. The foreign commits stay in the
branch history.
- A branch that was rewritten or recreated since a previous sync is
reported the same way. The very first sync, when the App has never
written the branch, is not.
- If it cannot update the branch (or `master` has no `docs/`, or the
branch is missing), it reports that in the same issue and exits
non-zero.
- A report already on the open issue is not posted again, so a problem
that persists does not add a comment per run. Only an issue the App
itself opened is reused.
- Text taken from commits is quoted and stripped of control characters
before it reaches the issue or the job log.
- **`.github/workflows/scripts/test_gitbook_sync.py`** (new): 33 tests
over an in-memory fake of the endpoints used. They run in the existing
PR status checker job.
- **`.github/rulesets/gitbook-sync-only.json`,
`gitbook-no-force-push-or-delete.json`** (new): the two rulesets, as the
request bodies for `POST /repos/{owner}/{repo}/rulesets`. Nothing
applies them automatically.
- **`docs/content/contribute/index.md`, `docs/AGENTS.md`**: docs changes
go to `dev`; never commit to `gitbook` or edit pages in GitBook.
**Configuration:**
- Uses the existing `BATCH_BOT_APP_ID` variable and
`BATCH_BOT_PRIVATE_KEY` secret. The token is requested with `contents:
write` and `issues: write` only.
- Optional new repository variable `GITBOOK_SYNC_NOTIFY`: who to mention
on a report. The default mentions `@Significant-Gravitas/maintainers`
and `@ntindle`; the App cannot see organization teams today, so the team
mention may not notify.
**What happens when this reaches `master`:**
- The release push itself triggers the first run. It writes one commit
on `gitbook` that removes everything except `docs/` (about 6,000 files)
and brings `docs/` to `master`'s. GitBook then imports the Platform and
Integrations spaces; Home is unchanged.
- Nothing on `gitbook` is lost: its tree equals `dev` as of 2026-09-14,
which `master` contains. Anything merged into `gitbook` between now and
that release would be dropped without a report, because the first sync
is silent by design.
**Manual steps after the first successful run (admin):**
1. Apply the two rulesets: `gh api -X POST
repos/Significant-Gravitas/AutoGPT/rulesets --input
.github/rulesets/gitbook-sync-only.json`, then the same with
`gitbook-no-force-push-or-delete.json`.
2. Move #14048 to `dev` and close #15157; PRs into `gitbook` cannot be
merged once the rulesets are on.
3. In GitBook: stop change requests being merged in the three synced
spaces, and remove Git Sync from the two unused spaces that still point
at this branch.
**What this does not do, or has not been proven:**
- GitHub cannot stop a change request being merged inside GitBook. Such
a change goes live on the site, fails to push, and is overwritten by the
next copy.
- Three steps are only exercised by the first real run: the App (which
has no `workflows` permission) writing a commit that removes workflow
files, the App's ruleset bypass applying to an API ref update, and
GitBook importing an update made through the API. A rejected write is
reported and fails the run; the fallback is for an admin to push that
first commit.
- The App's key is a repository-level secret, so anyone who can push a
workflow to any branch could mint its token. The rulesets keep out
GitBook, pull-request merges and ordinary pushes; they are not a barrier
against people with write access.
- A hand-made commit that copies the snapshot format exactly is treated
as the sync's own.
### Agents and large language models used
Claude Code (model: unknown)
### 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] `python -m unittest discover -s .github/workflows/scripts -p
"test_*.py"` passes (54 tests, 33 new), prints no workflow commands and
writes nothing to the step summary
- [x] Dry run against this repository with a read-only token
(`DRY_RUN=1`): reads `master` and `gitbook`, detects a first sync, and
plans one commit on top of `gitbook@fb7c677bd3`
- [x] The single-entry tree built from `master`'s `docs/` is identical
to `master`'s `docs/` (checked locally with `git mktree` and `git diff`)
- [x] Both ruleset files match the shape of the live `batch-rollup
bot-only` ruleset
- [ ] First real run on `master` (only possible after release; see
above)
<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>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> The first run on `master` will rewrite `gitbook` to a docs-only tree
and changes how published docs are updated; misconfiguration or rulesets
not applied could block sync or leave stale docs until fixed.
>
> **Overview**
> Adds **automated one-way sync** from `master`'s `docs/` to the
`gitbook` branch (what GitBook publishes), replacing manual sync PRs and
direct edits on `gitbook`.
>
> A new **`docs-gitbook-sync`** workflow runs on pushes to `master`,
daily, and on dispatch. It mints a **batch-bot GitHub App** token and
runs `gitbook_sync.py`, which fast-forwards `gitbook` with a
**docs-only** commit tagged `Synced-From: <master sha>`. If the branch
head was changed by anything else, the script **opens or updates an
issue** (with deduped reports), restores `master`'s docs on top, and
**fails the job** so the drift is visible. Two **ruleset JSON files**
document branch rules: no delete/force-push, and updates allowed only
for the sync App (applied manually by admins).
>
> Contributor docs in **`docs/AGENTS.md`** and
**`docs/content/contribute/index.md`** now say to PR **`dev`**, not
`gitbook`, and warn that GitBook edits are overwritten.
**`test_gitbook_sync.py`** adds broad unit tests for sync, reporting,
and API retry behavior.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
|
||
|
Nicholas Tindleandunknown
|
f3e05a73e1 |
docs(platform): move engineering notes out of the published docs folder (#15163)
### Why / What / How
**Why:** `docs/platform/` is published at agpt.co/docs, and a page goes
live once `SUMMARY.md` lists it. Engineering notes were kept in the same
folder, so one line in `SUMMARY.md` was all that separated them from the
public site. Two of them, the activation metrics contract and the
PostHog tracking plan, had already been added to the navigation under
"Using the Platform". They are not live only because the site is built
from the `gitbook` branch, which is behind `dev`. Agents also had no
stated place to put a note that isn't a page for the site, so
`docs/platform/` was the default.
**What:** Engineering notes get their own folder, `docs/engineering/`,
which no GitBook space reads. The eleven files in `docs/platform/` that
are not pages for the site move there, the two analytics pages leave the
navigation, and the agent guides say where a document goes. A test
requires every file in `docs/platform/` to be listed in its
`SUMMARY.md`.
**How:** The files are moved with `git mv`, so history follows them.
References to the old paths are updated: five code comments, the backend
agent guide, and one link on a published page. The test lives in
`.github/workflows/scripts/`, where the PR status checker already runs
every `test_*.py` on each pull request and merge group, so it needs no
new workflow.
### Changes 🏗️
- **Moved to `docs/engineering/`** (content unchanged apart from two
relative links in `hosted-mcp-catalog.md`):
- `activation-metrics.md`, `tracking-plan.md` (both were in
`SUMMARY.md`)
- `feature-flags.md`, `org-feature-map.md`,
`workspace-media-architecture.md`, `codex-subscription-preview.md`
- `releases/clay-rock-v1.md`, `releases/clay-rock-v2.1.md`
- `contributing/hosted-mcp-catalog.md`,
`contributing/oauth-integration-flow.md`, `contributing/tests.md` (now
at the top of `docs/engineering/`)
- **`docs/platform/SUMMARY.md`**: removed "Activation Metrics &
Experiments" and "PostHog Tracking Plan".
- **`docs/platform/integrations-and-credentials.md`**: the "Maintaining
MCP Integrations" link now uses the note's GitHub URL on `dev`, because
the relative path does not exist on the docs site. It resolves as soon
as this merges.
- **Path updates**: `posthog_client.py`, `posthog_events.py`,
`product_analytics.py`, `posthog-base-properties.ts`,
`posthog-events.ts` (comments only) and
`autogpt_platform/backend/AGENTS.md`.
- **`docs/engineering/README.md`** (new): what the folder is for, that
it is not on the docs site, and that it is still public.
- **`AGENTS.md`, `docs/AGENTS.md`**: a short "where a document goes"
rule. Pages for people outside the team (using, self-hosting or
contributing) go in the published folders; the team's working documents
go in `docs/engineering/`; when unsure, `docs/engineering/`.
- **`.github/workflows/scripts/test_docs_layout.py`** (new): fails when
a Markdown file under `docs/platform/` is not listed in
`docs/platform/SUMMARY.md`, and when any published folder's `SUMMARY.md`
lists a page outside its own folder or one that does not exist. The
failure message says to move the file to `docs/engineering/` unless it
is a page meant for the site.
**What this does not do:**
- The test checks that a file is listed, not who it is written for. A
note that is added to `SUMMARY.md` still passes, so that remains a
review call.
- AutoPilot's documentation search indexes every Markdown file under
`docs/`, so it still returns these notes, as it did when they were in
`docs/platform/`. For two of them (`tests.md`,
`oauth-integration-flow.md`) the link it cites used to redirect to a
live page and now returns 404; the other nine already did. Keeping
unpublished files out of that index is a backend change for a follow-up.
- `master` still lists the two analytics pages until this change is
released. Nothing publishes from `master` today, but a docs sync from
`master` before that release would put them on the site.
No published page changes on the live site from this PR: the site is
built from the `gitbook` branch.
### Agents and large language models used
Claude Code (model: unknown)
### 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] `python -m unittest discover -s .github/workflows/scripts -p
"test_*.py"` passes (21 tests, 8 new)
- [x] The new test fails when an unlisted file is added to
`docs/platform/`
- [x] The new test fails when `docs/platform/SUMMARY.md` lists a file in
`docs/engineering/`
- [x] Every relative link in the moved files resolves, the same as
before the move
- [x] No file in the repository still references an old path
- [x] `docs/platform/` has no Markdown file left that `SUMMARY.md` does
not list
<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:
- [ ] `.env.default` is updated or already compatible with my changes
- [ ] `docker-compose.yml` is updated or already compatible with my
changes
- [ ] 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>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Documentation layout, link, and comment updates plus a CI docs guard;
no application runtime, auth, or data-path changes.
>
> **Overview**
> Engineering and internal docs are split from the GitBook-published
tree by introducing **`docs/engineering/`** and moving team-only notes
(tracking plan, activation metrics, runbooks, contributing internals,
etc.) out of **`docs/platform/`**. **`docs/platform/SUMMARY.md`** drops
the two analytics pages that were one nav line away from going public,
and agent guides (**`AGENTS.md`**, **`docs/AGENTS.md`**) now spell out
published vs engineering placement.
>
> References are retargeted: PostHog-related code comments and
**`autogpt_platform/backend/AGENTS.md`** point at
**`docs/engineering/`**, and the published integrations page links to
the MCP catalog note via a **GitHub `dev` URL** because that path is not
on agpt.co/docs.
>
> **`.github/workflows/scripts/test_docs_layout.py`** enforces that
every `.md` under **`docs/platform/`** appears in
**`docs/platform/SUMMARY.md`** and that published **`SUMMARY.md`** files
only list real pages in their own folder—hooked into existing PR
**`test_*.py`** discovery in **`.github/workflows/scripts/`**.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
|
||
|
Nicholas TindleandClaude Fable 5.1
|
12225b6a0a |
ci(repo): stop an out-of-quota Copilot review from blocking every merge (#14965)
### Why / What / How
**Why.** Since about 23:30 UTC on 2026-09-26 no PR in this repo can
merge. GitHub's Copilot code review is out of quota (its run ends with
HTTP 402, "You have exceeded your monthly quota") and posts a
`copilot-pull-request-reviewer` check run that concludes `failure` on
every new head. The required `Check PR Status` job treats any
non-passing check run as a failure, so it fails too. #14884 and #14964
are blocked by exactly this tonight; anything opened tomorrow will be as
well until the quota resets.
**What.** The checker skips the Copilot reviewer's check run, completed
or still running. Its output is review comments, so it is advisory and
never gates a merge; the other review bots (Cursor Bugbot, Vercel)
already report `neutral` when they cannot run, which the checker already
accepts. A real failure beside it still fails the check.
**How.** `ADVISORY_CHECK_RUNS = {"copilot-pull-request-reviewer"}` and
an `is_advisory()` guard in `process_check_runs()` and in the
in-progress wait loop of `check_actions_status.py`; three unit tests
(advisory failure ignored, advisory in-progress does not hold the check,
a real failure beside it still fails). The checker workflow runs the
script from the PR's own checkout, so this PR's `Check PR Status` uses
the fixed rule.
Once merged, re-running `Check PR Status` on the blocked PRs clears
them. The quota itself is an org setting (Copilot code review usage);
this only stops it from blocking merges.
### Agents and large language models used
- Claude Code with Claude Fable 5.1
### 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] `python -m unittest discover -s .github/workflows/scripts -p
"test_*.py"`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Narrows merge-gating to ignore one named advisory check; substantive
CI conclusions are unchanged and covered by new tests.
>
> **Overview**
> **Check PR Status** no longer treats GitHub Copilot’s
`copilot-pull-request-reviewer` check as merge-blocking when it fails or
is still running (e.g. HTTP 402 quota errors that conclude `failure` but
do not reflect code health).
>
> The script introduces an **advisory** allowlist and skips those runs
in both conclusion evaluation and the “wait for in-progress checks”
loop, with logging when they are ignored. **Real CI failures still
fail** the gate when they appear alongside an ignored Copilot run.
>
> Three unit tests cover: advisory `failure` ignored, advisory
`in_progress` not blocking completion, and a non-advisory failure still
failing.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
|
||
|
BentlyandClaude Opus 5.5
|
0a6d563772 |
ci(platform): cache the e2e Docker layers in GHCR instead of the Actions cache (#14892)
> **Stacks on #14877.** The base is #14877's branch, so the diff is only the cache change. Once #14877 merges, this retargets to `dev`. ### Why / What / How **Why:** the e2e job's BuildKit layer caches live in the Actions cache (`type=gha`). That cache is capped at 10 GB per repo and churns, so on #14877 the layer caches were evicted within about 30 minutes, and the backend image rebuilt cold (260–313 s) on most runs. **What:** the e2e image builds (backend + frontend, via `buildx bake`) now use a registry cache in GitHub Container Registry (GHCR) instead of the Actions cache. **How:** - One package, `ghcr.io/significant-gravitas/autogpt-platform-e2e-buildcache`, with a tag per build target: `backend-server`, `backend-migrate`, `frontend-prod`. One package means one set of settings for an admin, and the backend targets share blobs. - **Every run reads it** (`cache-from type=registry`). - **Only these runs write it** (`cache-to mode=max`): pushes to `dev`, the merge queue, and a manual run with `publish_build_cache` ticked. Pull requests never write, including same-repo ones. - **It degrades, not fails.** The login step is `continue-on-error`. BuildKit treats a cache it can't import as a warning. The export has `ignore-error=true`. A missing package, a private package, or a missing permission costs a cold build, never a red job. The tester VM and this PR's own CI both show this (below). ### Timings The package can't exist until something writes it, and only `dev` pushes and the merge queue write. So every run of this PR's e2e job is **cold** by construction: that measures the worst case and the degrade path. The warm path was measured separately on the same runner type. A temporary job on `ubuntu-latest` used a runner-local registry as a stand-in for GHCR. It is removed again (`f954fb8`), and the diff is back to the single change. **e2e job, wall time** | | big-boi (median, `dev`) | #14877 (Actions cache) | this PR, cold (no GHCR cache yet) | this PR, warm (**estimate**) | |---|---|---|---|---| | Job | **10.9 min** | **13.4–14.8 min** | **16.8 / 19.9 / 13.2 / 14.2 min** (runs 1–4) | **≈ 9–10 min** if the seed-data cache hits; ≈ 12–13 min if the PR changes backend code, since the seed step then runs again (~3 min) | | Backend bake | — | 1.6–5.2 min | 4.9–5.3 min | 10–45 s (measured) | | Frontend bake | — | 5.0–8.9 min | 4.6–9.2 min | 6 s with no frontend change, ~3–4 min with one (measured 346 s without the Next.js webpack cache, which the e2e job does seed) | | Tests | 28 | 28 | 28/28 · 28/28 · 28/28 · 27/28 † | unchanged | - Run 1 missed both the seed-data cache and the Next.js cache. Run 2 missed the seed-data cache, and seeding took 6.1 min (3.2 in run 1). Run 3 hit both. Run 4 hit both. - † Run 4 built the same tree as run 1, which passed 28/28. Its one failure was `library-happy-path › user can edit a saved agent…`: the click on `library-agent-card-open-in-builder-link` timed out. The failure screenshot shows the card rendered with See tasks / View / Chat and no builder link, which is a library UI timing issue, not a build difference. It was not re-run by hand. - **The warm column is an estimate.** It takes run 3's critical path and swaps in the warm bake times measured on the runner. The real warm number comes from the first PR after the first `dev` push following merge. **Registry cache measured on `ubuntu-latest`** (temporary job, runner-local registry; the backend and frontend bakes run side by side, as in the e2e job) | Pass | Backend bake | Frontend bake | Cache export prep | Steps `CACHED` | |---|---|---|---|---| | Cold, writes the cache (`dev` / merge-queue path) | 292 s | 523 s | 203 s | 8 | | Fresh builder, reads only, same source | **10 s** | **6 s** | 0 | 68 | | Fresh builder, reads only, one backend + one frontend file changed | **45 s** | 346 s | 0 | 56 | **Cost on the writing runs.** A cold `mode=max` export took about 200 s of prep on the runner: about 120 s backend, which overlaps the frontend build, and about 80 s frontend, which is on the critical path. After the first write, unchanged layers are already in the registry, so later exports should be much smaller. That is expected, not yet measured. The merge queue is new as a writer: #14877 wrote only from `dev` pushes. ### Admin steps Nothing is needed before merge, and nothing here is assumed to exist. 1. **The package gets created on its own.** The first `dev` push or merge-queue run after this merges creates `autogpt-platform-e2e-buildcache` as a **private** org package. The org already allows this: `dev` pushes already create and write `autogpt-single-container-buildcache` with `GITHUB_TOKEN` + `packages: write`, the same way (checked in run 36044723983: `writing cache manifest … done`). 2. **Then an org owner or package admin** opens *Org → Packages → autogpt-platform-e2e-buildcache → Package settings*: - **Manage Actions access:** `Significant-Gravitas/AutoGPT` must be listed with role **Write**. GitHub normally adds the publishing repo automatically when its `GITHUB_TOKEN` creates the package. Add it if it is missing, for example if someone created the package by hand. Without it, writes fail quietly (`ignore-error`) and builds stay cold. - **Danger Zone → Change visibility → Public.** This is needed for **fork PRs**: their token is read-only, and I have not verified that it can read a private org package. Anonymous pulls of a public package always work. If *Public* is greyed out, *Org settings → Packages → Package creation* has to allow public packages. Making it public is safe: - The layers are built from public source. - `frontend/.env`'s one generated secret (`BETTER_AUTH_SECRET`) is blanked before the build. - `backend/.env`, where the OpenAI key goes, is excluded from the build context by `.dockerignore` (`**/.*`). 3. **Check it worked:** the next PR's *Build backend Docker images* log should show `importing cache manifest from ghcr.io/…:backend-server` followed by `CACHED` steps, not `failed to configure registry cache importer`. ### Changes 🏗️ - `.github/workflows/platform-fullstack-ci.yml` (`e2e_test`) - Adds job-level `permissions: packages: write` next to `contents: read`. This is the only job with it. Permissions can't be conditional on the event. A fork PR's token is read-only regardless, and a same-repo PR run logs in but never gets a `cache_to`. - Replaces `crazy-max/ghaction-github-runtime` (the step that exposed the Actions cache to buildx) with `docker/login-action` for `ghcr.io`, using `GITHUB_TOKEN` and `continue-on-error`. It is pinned to the same SHA as the single-container workflow. - `WRITE_BUILD_CACHE`: dev push, `merge_group`, or `workflow_dispatch` with `publish_build_cache`. - Drops the per-PR `type=gha,mode=min` frontend export and the hash- and branch-scoped GHA cache keys. *Trade-off:* a second push to a PR that changed the frontend rebuilds it, rather than reusing that PR's own earlier image. The Next.js webpack cache still applies. - `.github/workflows/scripts/docker-ci-fix-compose-build-cache.py`: writes `type=registry` `cache_from` / `cache_to` into the resolved Compose file (`--cache-image`, `--write-cache`). Only this workflow uses the script. - Not changed: the Next.js webpack cache and the seed-data cache stay in `actions/cache`. The tests, workers, timeouts and retries are unchanged, with nothing skipped. ### Related - AutoPwuts' proposal: make the poetry caches restore-only on PRs. Each PR push currently saves about 5 GB of poetry caches, which is what churns the 10 GB Actions cache. It is not in this PR. With this PR, the Docker layers no longer compete for that space. ### Agents and large language models used - Claude Code with Claude Opus 5.5 (1M context) ### 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] Tester VM (tester-1): replay the job's Prepare + bake steps with this script against local registries. Cold write: exit 0, all three tags written. Fresh-builder read: 69 steps `CACHED`, no export. Registry answering 401 to both read and write: exit 0, with the import and export errors logged as warnings. The real GHCR name before the package exists: exit 0 (`403` on the anonymous token, built cold). - [x] This PR's CI with the package missing: `failed to configure registry cache importer: … not found`, cold build, e2e 28/28 (run 1) - [x] Warm path on `ubuntu-latest`: temporary job with a runner-local registry (table above), since removed - [ ] Real warm e2e minutes from GHCR: only possible after merge (first `dev` write) #### 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**) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 (1M context) (Claude Code) <[email protected]> |
||
|
BentlyandClaude Opus 5.5
|
fbc0d24c7b |
ci(platform): speed up the full-stack e2e job on the free runner (#14877)
> **Stacks on #14870.** This branch starts from #14870's branch, so the diff includes the move to `ubuntu-latest` and `PLAYWRIGHT_WORKERS=4`. Review #14870 first; this PR only adds the speed-ups on top. ### Why / What / How **Why:** on the free 4-vCPU runner (#14870) the full-stack e2e job takes **17.4 min**, against a **10.9 min** median on `big-boi`. The target was ≤10 min without dropping tests, retries, timeouts or assertions. **What:** a hill-climb, one change per push. Each push is one CI run of this PR. **Result: best run 13.4 min, last run 14.8 min. It did not reach 10 min.** The job now runs its two long chains side by side, a backend chain (images, stack, seed data) and a frontend chain (Next.js image). Each takes about 5 to 8 minutes on a 4-vCPU runner unless the caches hit, and the repo's Actions cache evicts them within the hour. **How:** every run keeps the full suite: 28 tests, `--retries=0`, the same timeouts and assertions. #### Hill-climb results | # | Change (commit) | e2e job | Next.js build | Tests | What happened | |---|---|---|---|---|---| | 0 | #14870 baseline | 17.4 min | 345 s | 28/28 | | | 1 | Next.js webpack cache between builds (`e1b2429`) | 17.8 min | 305 s | 28/28 | The export saved an **empty** cache: a `--no-cache` build is handed a fresh cache mount (reproduced on tester-1) | | 1b | fix: export without `--no-cache` (`f34056c`) | 18.7 min | 339 s | 28/28 | Cold run that seeds the cache: 3.7 GB unpacked, 380 MB stored | | 2 | **Backend stack starts while the frontend image builds** (`5acb663`) | **13.4 min** | 307 s | 28/28 | Warm Next.js cache: compile 157 s (cold: 222–231 s) | | 3 | **Skip Next.js lint + type check in the e2e image** (`94fc283`) | 13.5 min | 358 s | **27/28** | Compile cold again: `next.config.mjs` changed, and it is a webpack build dependency. `library › start and stop a saved task` timed out (see below) | | 4 | **Frontend build context made deterministic**; PR runs export the frontend image cache; the Next.js export waits for the tests (`cbb09c7`) | 16.1 min | 178 s | 28/28 | Frontend side fast (compile 105 s), but the dev backend image cache had been evicted: backend build 313 s | | 5 | Seed embedding backfill 300 at a time instead of 100 (`eceb49e`) | 15.0 min | 400 s | 28/28 | No gain: 19 rounds instead of 57, still 140 s. The Next.js cache saved in run 3 had been **evicted** 40 min later | | 6 | Revert 5 (`e827e0b`) | 14.8 min | 165 s | 28/28 | Warm Next.js cache. The backend image cache was partly evicted (260 s), and seeding missed because dev's backend changed | Next.js build = the `pnpm build` step inside the frontend image. Evidence (job logs, step timings, VM logs) is in the work archive: `ci-free-runner-e2e/evidence/hillclimb/`. #### What each change is worth - **Start the backend stack while the frontend builds** (−4 to −5 min, cache-independent). The backend images finish minutes before the Next.js build. The job now runs migrations, starts the backend services and seeds data during the frontend build, then starts the frontend last and waits for `:3000` before Playwright. - **Deterministic frontend build context** (a bug fix; it applies on `big-boi` too). `make init-env` writes a random `BETTER_AUTH_SECRET` into `frontend/.env`, which is in the image's build context. So the `COPY autogpt_platform/frontend/ .` layer, and everything after it, **never hit the cache on any run, dev pushes included**. The resolved compose file already carries the secret into the container, so the workflow now blanks it in `frontend/.env` after resolving. On tester-1, a second bake after a fresh `make init-env` was fully `CACHED` (34 s vs 979 s cold). The container still gets a 64-char secret at runtime, and `/api/auth/jwks` returns 200. - **Skip Next.js lint + type check in the e2e image** (−50 to −90 s of Next.js build). `pnpm types` already runs in this workflow's `check API types` job, and `pnpm lint` runs in Frontend CI. Other builds are unchanged: `NEXT_SKIP_BUILD_CHECKS` defaults to `false`. - **Next.js webpack cache** (compile 103–157 s warm vs 222–340 s cold, but it costs ~48 s to restore and load, and ~60 s to export on runs that save). It only pays off when the entry survives, and one was evicted within 40 minutes. #### Why not 10 minutes On the free runner the job is roughly: setup ~1.3 min, then **max(backend chain, frontend chain)**, then Playwright ~3.5 min and teardown ~1 min. - Backend chain: images 1.5–5 min (depends on layer-cache hits) + migrate 0.3 + start 1.5–2.2 + seed 3 min on a seed-cache miss - Frontend chain: 3–7 min (depends on the Next.js cache and layer cache) 10 min needs both chains near 4 min, which needs the backend image cache, the seed cache and the frontend cache to all hit. The repo's Actions cache is at its cap (10–18 GB of entries during this work), and it evicted the dev backend index, the dev frontend index, the Playwright browser cache and this PR's Next.js cache within about an hour each. Every push here also changed the workflow file, which is part of the seed-cache key, so seeding (3 min) never hit. ### Recommendation 1. **Merge the cache-independent parts**: the split bake, the deterministic frontend context and the lint/type skip. They take the free-runner job from ~17.4 to ~13.5–15 min, and the context fix makes the frontend image reusable on any runner. 2. **The Next.js cache is only worth keeping if the Actions cache stops churning.** It adds a 380 MB entry per PR and per dev push. Drop those steps if the cache limit stays as it is. 3. **To actually get to ≤10 min**, pick one: - make the caches stick: raise the repo's Actions cache limit (storage above 10 GB is billed), or move the Docker layer cache to a registry (`type=registry` on ghcr.io, not bound by the Actions cache cap; needs `packages: write` on dev pushes) - or run e2e on an 8-core larger runner (~$0.022/min, about half of big-boi) with these changes. Not measured here. **Flaky test:** `library › start and stop a saved task` (stop API wait, 15 s) failed in run 3 here, in #14870's 8-worker run, and in the tester-1 replay of this branch, which had no cache export running. On that VM #14870's head also scored 27/28 with a different test (marketplace). This looks like a load-sensitive test rather than a regression from these changes, but it fails more often on 4 vCPUs. ### Changes 🏗️ - `.github/workflows/platform-fullstack-ci.yml` (`e2e_test`): - bake the backend images and the frontend image as two background steps; start migrations, the backend services and seeding after the backend images; start the frontend last (`--no-deps`) and wait for `http://localhost:3000` - blank `BETTER_AUTH_SECRET` in `frontend/.env` after `docker compose config`, so the build context is the same on every run - PR runs export the frontend image's layer cache (`mode=min`, frontend only); dev pushes are unchanged (`mode=max`, both) - frontend bake sets `NEXT_SKIP_BUILD_CHECKS=true` - Next.js cache: restore `/tmp/next-build-cache` (key = hash of `next.config.mjs` + lockfile, then PR number or SHA), load it into the BuildKit cache mount, export it after the Playwright suite, save it at the end (once per PR per key, per push on dev/master, never from the merge queue) - `.github/workflows/scripts/docker-ci-fix-compose-build-cache.py`: `--cache-to-components` limits which components export cache (default: all, so existing calls are unchanged) - `autogpt_platform/frontend/Dockerfile`: `.next/cache` as a BuildKit cache mount (`id=next-build-cache`); `ARG NEXT_SKIP_BUILD_CHECKS="false"` - `autogpt_platform/frontend/next.config.mjs`: `eslint.ignoreDuringBuilds` / `typescript.ignoreBuildErrors` only when `NEXT_SKIP_BUILD_CHECKS=true` ### Agents and large language models used - Claude Code with Claude Opus 5.5 (1M context) ### 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] Every CI run keeps the full suite: 28 tests, retries 0, unchanged timeouts (6 of 7 runs 28/28, run 3 27/28, see above) - [x] Record e2e job minutes and Next.js build seconds for each change (table above) - [x] tester-1: a Next.js build pinned to 4 CPUs, cold vs warm webpack cache (compile 9.3 → 4.1 min) - [x] tester-1: a `--no-cache` build gets an empty BuildKit cache mount, while a normal build shares it (probe scripts) - [x] tester-1: replay of the new job flow: two fresh `make init-env` runs give the same `frontend/.env` and a fully cached second frontend bake; the backend stack is up and seeded before the frontend starts; the frontend has its runtime secret and JWKS answers 200; Playwright 27/28 (the flaky stop-task test) #### 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**) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 (1M context) (Claude Code) <[email protected]> |
||
|
|
d46e93bacb |
ci(platform): overlap full-stack builds and harden E2E validation (#14281)
### Why / What / How
Full-stack CI was serializing independent setup and image-build work and
could accept incomplete test evidence. This layer overlaps independent
work, reuses deterministic seed data, and validates every Playwright
result and coverage upload without retries or weakened assertions.
This PR contains only the full-stack workflow and its supporting
scripts/UI/test fixes. The signup hydration and sidebar changes are
necessary to make zero-retry browser tests reliable: signup waits for
auth initialization, task creation no longer depends on unrelated list
queries succeeding, and failed lists expose a usable retry path instead
of leaving the detail panel loading forever. They are not generic UI
refactoring.
Stack order after the September 22 restack: this PR -> #14282
(appliance) -> #14284 (docs). Classic, backend, and frontend layers have
already merged. #14283 remains closed and is excluded. #14508 was
redundant with merged #14277 and has been closed. Older
approvals/timings are historical, not validation of this head.
Pwuts's earlier comparison measured full-stack wall time at 14m30s ->
9m19s (-36%) and runner-minutes at 18.53 -> 12.58 (-32%). This is
historical single-wave evidence from the review, not a new benchmark on
the September 22 head.
### Changes 🏗️
- Overlap BuildKit/image builds and independent setup; preserve current
dev's `make init-env` fresh-secret bootstrap.
- Limit Docker cache export to dev pushes or explicit
`publish_build_cache` dispatches; retain the ability to cache test
commits.
- Key seed-data reuse on its transitive inputs, and keep database
restore errors blocking.
- Evaluate the seed cache immediately after checkout, before fresh
secrets or resolved Compose files exist. A regression pins this
ordering; old runs of the same source used different keys when
runtime-generated files were hashed.
- Refresh only the eight marked dummy integration credentials after cold
seeding or cache restore, preserving their IDs and verifying decryption
under the fresh run key. Missing/wrong fixtures and failed updates block
CI; no runtime keys are cached or reused.
- Require 28 Playwright tests (current inventory: 28 tests in 9 files),
one successful attempt each, no skips/flakes, and validated coverage
before upload.
- Cover per-test report errors even when aggregate statistics look
clean.
- Fix signup hydration, task-list errors/recovery, and async
navigation/form assertions without test retries.
- Select successfully created runs/schedules/webhook triggers directly,
avoiding stale-empty-list count races; three new regressions fail
against the old handler.
### Agents and large language models used
Codex: unknown runtime model; gpt-daybreak-blue-latest contributed to
earlier review/fixes. Earlier work also credited Claude Opus 5 and human
reviewer Reinier van der Leer; existing commit attribution is retained.
### Checklist 📋
- [x] Changes and test plan listed.
- [x] Full-stack helper/validator regressions: 31 passed locally. The
cache-ordering test fails against the prior workflow and passes with the
fix; changed Python format/import/type checks pass and YAML parses.
- [x] Credential/embedding regressions: 19 passed locally, including
fresh-key readability, incomplete/wrong fixture sets, database failures,
failed encryption verification, CLI routing, and disconnect-on-failure.
An in-memory no-op refresh mutation fails the new regression. Daybreak
reviewed the change and found no blockers.
- [x] Frontend format, lint, and type checks passed locally.
- [x] Complete frontend suite with the first-item fix: 7,850 tests
passed, zero failures/skips/todos. After a test-only props-interface
cleanup, format/lint/types and all 56 affected sidebar/signup tests
passed again.
- [x] Earlier 6-failure hosted E2E run diagnosed and reproduced; no
browser assertion, retry or test-inventory weakening. CI verified the
application fix on predecessor
`3541822cd9835bb69b2b4f9fb08b2c868aeef6ee`; the new cache-ordering
commit changes no application code.
- [x] Predecessor [full-stack E2E and schema
checks](https://github.com/Significant-Gravitas/AutoGPT/actions/runs/35781921471)
passed: downloaded report confirms 28 passes, zero failures/skips/flaky
results; report and coverage validators passed.
- [x] Cold full-stack run on `47e3d7625d`:
[35792006029](https://github.com/Significant-Gravitas/AutoGPT/actions/runs/35792006029)
passed in 8m31s, including verification of all eight seeded credentials.
Seed creation took 1m49s; key was saved for reuse.
- [x] Hosted frontend shard failure on `47e3d7625d` isolated to a
synchronous input assertion racing the detail hook's effect. Two
remaining assertions now await their exact populated values, without
retries or timeout changes. All 26 trigger tests, formatting, lint and
type checks pass; Daybreak confirmed the fix preserves coverage.
- [x] Current `83f34c613f7ff2d2ca0c2a42170cfec308ef6319`: [same-head
cold/warm
E2E](https://github.com/Significant-Gravitas/AutoGPT/actions/runs/35793038476)
passed all 28 tests with zero skips/failures/flaky results. Wall time
9m19s -> 7m01s; identical key restored, seed creation skipped, all eight
credentials verified under the fresh key. Detailed phase timings are in
the review follow-up.
- [x] Current-head
[frontend](https://github.com/Significant-Gravitas/AutoGPT/actions/runs/35793038495):
7,856 tests passed, zero failures/errors/skips, verified from all four
JUnit artifacts.
[Backend](https://github.com/Significant-Gravitas/AutoGPT/actions/runs/35793038502):
all 18 jobs passed; coverage settled green.
- [x] Inherited [appliance
checks](https://github.com/Significant-Gravitas/AutoGPT/actions/runs/35793038488)
passed both architectures, smoke tests and scans; publication skipped.
Aggregate PR status and all current-head checks are green.
- [ ] Current-head approval. All 17 inline threads are resolved; Pwuts
is requested. `/reapprove` cannot restore bot-only approvals, and the
bot's fresh-review quota is exhausted. No approval or limit bypass is
used.
- [ ] Two quiet post-CI/review polls for the complete stack.
- [x] Existing generated environment setup and Docker Compose
configuration retained.
This layer changes backend test seeding and its focused tests, not
production backend source. Earlier comments about complete backend-tree
equivalence were correct for their recorded heads, but their run IDs are
not claimed as fresh evidence here. #14282 changes scheduler
configuration and needs its own backend validation.
The fresh `/review` request was answered with the repository's
three-reviews-per-five-hours limit. That limit is unchanged. Existing
bot approval and the independent Daybreak reviews are recorded
separately; no claim is made that the rate-limited bot reviewed the two
newest fixes.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes CI orchestration, credential re-encryption in test seeds, and
auth/library UX paths relied on by E2E; production signup behavior
shifts slightly but scope is mostly CI and test reliability.
>
> **Overview**
> **Full-stack CI** is reworked for faster, stricter E2E: the shared
frontend `setup` job is removed, BuildKit pull / image bake / DB startup
run in parallel with Playwright install, and Docker **cache export**
only runs on `dev` pushes or manual `publish_build_cache` dispatches
(compose cache script now allows an empty `--cache-to`).
>
> **E2E seeding** moves the SQL cache step immediately after checkout
with a broader `e2e-test-data-v3` key, restores the DB with
`ON_ERROR_STOP`, and always runs `e2e_test_data.py
--refresh-credentials-only` so cached credentials decrypt under each
run’s fresh encryption key. Contract tests pin those workflow
guarantees.
>
> **Test evidence** is tightened: Playwright runs with `--retries=0`, a
new `validate_playwright_json.py` enforces a 28-test floor and rejects
flakes/skips/multi-attempt results (even when aggregate stats look
clean), Cobertura is validated before Codecov upload, and validator
suites run in the API-types job.
>
> **Product fixes for zero-retry E2E:** signup shows a loading shell
until auth has initialized once (preserving draft input on refresh); the
library agent view surfaces sidebar fetch errors with retry, keeps **New
agent task** usable when lists fail, and selects newly created
runs/schedules/triggers directly instead of racing empty counts.
Playwright helpers wait for hydrated signup and harden upload/navigation
assertions.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
|
||
|
Abhimanyu YadavandGPT-6
|
57037db4a8 |
feat(backend): teach AutoPilot to propose the first expert hire (#14466)
### Why / What / How **Why:** A user with no hired experts currently gives AutoPilot no team context from which to propose a first teammate. **What:** Add a Head-of-AI brief and available template roster to eligible empty-team conversations, with explicit approval-based hiring guidance. **How:** Gate empty-roster context on the expert-team and delegation flags; keep solo expert sessions unchanged. Extend the existing delegation supplement without changing the cache-pinned system prompt. **Stack:** 7/7; base `Abhi1992002/copilot-team-cards`. Review only this layer’s diff and merge from the bottom upward. dev → bot-avatars → expert-avatar-tool → recommend-experts → braindump-voice → onboarding-wizard → copilot-team-cards → head-of-ai ### Changes 🏗️ - Add escaped roster context and graceful handling of missing templates. - Tell AutoPilot to propose one hire or custom expert at a time and wait for confirmation. - Add flag, empty-roster, failure-path, and prompt regression tests. - Reuse the backend feature flag from layer 3; no new configuration or schema changes. - Fix the CI status checker’s duplicate-run race: a passing equivalent workflow created at the same time satisfies a canceled duplicate; real failures remain blocking. ### Agents and large language models used Claude Code (model version unavailable for the complete snapshot); Codex with GPT-6 for stack preparation, conflict resolution, validation, and test corrections. ### 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] Copilot context, prompt, and expert-change suites: 116 tests passed. - [x] Backend formatting and type checks. - [x] CI status-checker suite: 10 tests passed, including concurrent-run regressions and replay of the actual failed GitHub snapshot. - [x] GitHub CI passes for this PR. Browser testing was not run locally. #### 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**) --------- Co-authored-by: GPT-6 (Codex) <[email protected]> |
||
|
Nicholas TindleandClaude Opus 5
|
448a85c9b5 |
feat(platform): let a user pick the connection every new chat starts on (#14078)
### Why / What / How
**Why.** AutoPilot can already run a chat on a user's ChatGPT plan — but
only when something names that route per session. Every path that opens
a chat *without* a request to read a route from passed no route at all
and silently took `platform`:
| Entry point | Before |
| --- | --- |
| Bot links (Discord et al) — `platform_linking/chat.py:264` | no route
arg → `platform` |
| Scheduled AutoPilot turns — `executor/scheduler.py:354` | no route arg
→ `platform` |
| Assistant push messages (expert posts, briefings) — `copilot/db.py` |
no route arg → `platform` |
| Dream passes — `copilot/dream/apply.py` | no route arg → `platform` |
So a connected ChatGPT account was ignored everywhere except a chat the
user started by hand in the web app. There was also no way to *express*
the preference in the first place.
**What.** One saved choice — provider **and** credential — honoured by
all of the above plus a fresh `/copilot` session.
- `User.defaultChatAuthProvider` + `defaultChatCredentialId`, both
nullable. `NULL` means *automatic*, which is precisely today's
behaviour: nothing re-routes on deploy, and there is no backfill.
- `PUT /api/chat/transports/default` saves or clears it. `GET
/api/chat/transports` is unchanged in shape; its `default` flag now
reflects the saved choice.
Storing the credential id alongside the provider is deliberate —
"ChatGPT" stops being an answer the moment a user can link more than one
account, and this is the contract the Settings UI will keep.
**How.** Transport enumeration moves out of
`api/features/chat/routes.py` into a new `copilot/transports.py`. That
move *is* the fix: the unrouted callers can't import the API layer,
which is why the setting couldn't be honoured on those paths before. The
route handler keeps its function name, so its `operationId` — and the
generated `useGetV2ListChatTransports` hook — are untouched.
Validation reuses the codes `POST /sessions` already returns for the
same mistakes (`codex_credential_required`,
`codex_credential_not_found`, `codex_credential_not_allowed`), so a
client only has to understand one vocabulary.
#### Healing is deliberately *not* to platform
A saved connection that can no longer be honoured — credential deleted,
entitlement lapsed — falls through to whatever the server would have
picked on its own. Healing specifically to `platform` would strand
exactly the users who have no platform credentials, since a self-hosted
install may have no platform route at all. The saved row is left in
place, so reconnecting restores the choice. Same heal-and-tell shape
#14059 gave the credential field.
#### What is deliberately left alone
- **Sub-sessions** inherit the parent session's route — inheritance
beats the default.
- **The AutoPilot block** keeps the explicit `transport` field from
#14070; that's the point of it.
- **Builder chat** stays platform-only.
- **Existing sessions** keep the route they were created with. This
decides where a chat *starts*, never where one in progress continues.
### Changes 🏗️
- `backend/copilot/transports.py` (new) — transport discovery,
`resolve_default_chat_route`, save/validate
- `PUT /api/chat/transports/default`; `GET /api/chat/transports` now
reflects the saved default
- Additive migration + two nullable `User` columns
- The four unrouted entry points above now resolve the default
- Frontend: the copilot store starts *unset* instead of hardcoded
`platform`, so the server default can land; the composer label resolves
against the effective selection so it never flashes "Choose connection"
- `openapi.json` regenerated (+65 lines, no deletions)
**The UI to set this lands in the next PR** (AI subscriptions section in
Settings → Integrations). This PR is the contract and the plumbing.
### 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] 20 unit tests in `copilot/transports_test.py` — saved choice beats
the server pick, exactly one transport is ever default, the account (not
just the provider) is pinned, heal on disconnect / lost entitlement /
no-platform-route, unknown provider reads as automatic, unrouted callers
never raise, and every save-validation branch
- [x] 9 route tests in `chat/routes_test.py` — endpoint contract, and
that a new session with no route takes the saved default while an
explicit route still beats it
- [x] 1 regression test in `data/user_test.py` — see below
- [x] 6 frontend tests in `helpers/__tests__/copilotLlmAuth.test.ts`;
full frontend suite green (425)
- [x] **End-to-end against a single-container build of this branch:
17/17.** Real HTTP through `/api/proxy`, including
`defaultChatAuthProvider` read back out of Postgres and a new session
picking up the saved default
- [x] `/copilot` composer renders clean with the store starting `null`,
no console errors
- [x] **Codex happy path end-to-end against a real linked ChatGPT
account: 20/20.** The connection is discoverable and labelled `ChatGPT`;
saving it pins provider *and* credential id in Postgres; a new session
with no route runs on that exact account and the route is persisted on
the session row; an explicit `platform` request still beats it; clearing
returns the next session to platform
#### A regression this caught
The first e2e run failed 11/16: `GET /transports` and `POST /sessions`
returned **400 `User not found with ID`** for a freshly signed-up
account. Reading the saved default pulled in the platform `User` row,
which is created lazily by `POST /auth/user` — a call the frontend makes
separately after sign-in. Neither endpoint touched that table before
this change, so the window between sign-up and that call was broken.
Unit tests mock at exactly that boundary and could never have seen it.
Fixed (a missing row reads as "nothing saved"), pinned by a test in
`data/user_test.py`, and the e2e now asserts the pre-`/auth/user` case
explicitly.
#### For configuration changes:
- [x] `.env.default` is updated or already compatible with my changes —
no new configuration
- [x] `docker-compose.yml` is updated or already compatible with my
changes — unchanged
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes which LLM/auth route new and automated chats use across
several production entry points and adds user-persisted preferences,
though behavior stays backward-compatible when unset and is heavily
covered by tests.
>
> **Overview**
> Adds a **persisted default AutoPilot connection** (provider +
credential id on `User`) and **`PUT /api/chat/transports/default`** to
set or clear it; **`GET /api/chat/transports`** now marks exactly one
transport as `default` from that choice (with heal/fallback when the
saved account is gone).
>
> Transport logic moves into **`backend/copilot/transports.py`**, and
**unrouted session creation** (web sessions with no explicit route,
Discord/bot linking, scheduled turns, dream passes, assistant push
threads) now calls **`resolve_default_chat_route`** so those paths honor
the same default as Copilot. The Copilot UI store starts with
**`copilotLlmAuth: null`** and adopts the server default via
**`resolveCopilotLLMAuthSelection`**; OpenAPI is updated for the new
endpoint (Settings UI to call it is follow-up).
>
> Separately, the **repo PR status checker** paginates GitHub check-run
and workflow-run APIs, **ignores cancelled checks superseded by a newer
passing run** on the same workflow/SHA, runs **unit tests in CI**, and
drops noisy debug logging.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
|
||
|
Reinier van der Leer
|
43b25b5e2f |
ci(frontend): Speed up E2E test job (#12090)
The frontend `e2e_test` doesn't have a working build cache setup, causing really slow builds = slow test jobs. These changes reduce total test runtime from ~12 minutes to ~5 minutes. ### Changes 🏗️ - Inject build cache config into docker compose config; let `buildx bake` use GHA cache directly - Add `docker-ci-fix-compose-build-cache.py` script - Optimize `backend/Dockerfile` + root `.dockerignore` - Replace broken DIY pnpm store caching with `actions/setup-node` built-in cache management - Add caching for test seed data created in DB ### 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: - CI |
||
|
BentlyandReinier van der Leer
|
d5d613e014 |
chore(backend): Downgrade poetry to 2.1.1 for dependabot (#10079)
Co-authored-by: Reinier van der Leer <[email protected]> |
||
|
Reinier van der Leer
|
ab3643388f |
ci: Fix workflow status checker script to work with merge_group runs
|
||
|
Reinier van der Leer
|
679245416f |
ci: Reduce PR Status Checker interval (#8137)
Reduce interval from 3 minutes to 30 seconds to reduce CI lag |
||
|
Swifty
|
ef7cfbb860 |
refactor: AutoGPT Platform Stealth Launch Repo Re-Org (#8113)
Restructuring the Repo to make it clear the difference between classic autogpt and the autogpt platform: * Move the "classic" projects `autogpt`, `forge`, `frontend`, and `benchmark` into a `classic` folder * Also rename `autogpt` to `original_autogpt` for absolute clarity * Rename `rnd/` to `autogpt_platform/` * `rnd/autogpt_builder` -> `autogpt_platform/frontend` * `rnd/autogpt_server` -> `autogpt_platform/backend` * Adjust any paths accordingly |
||
|
Nicholas Tindle
|
efcd0f93ed |
ci(all): take two on the global status checker (#7849)
* ci(all): fundamentally change how we do this * Update workflow-checker.yml * ci: dupe and move file in attempt to figure out why its not accessible * Update workflow-checker.yml * fix: sleep before checking, move files, improve code * Update workflow-checker.yml * Update check_actions_status.py * Update check_actions_status.py * Update workflow-checker.yml * Update workflow-checker.yml * ci: remove debug, add more * Update check_actions_status.py * Update check_actions_status.py * Update check_actions_status.py * Revert "Update check_actions_status.py" This reverts commit |
||
|
Nicholas Tindle
|
56b82369b6 | ci(all): verify the workflows as part of each run (#7500) | ||
|
Reinier van der Leer
|
650072eb99 | Fix CI/CD for Auto-GPT + docs site deployment | ||
|
Merwane Hamadi
|
8489052358 | Move Auto-GPT to autogpts/autogpt | ||
|
Reinier van der Leer
|
ffdc652605 |
Clean up GitHub Workflows (#3059)
* initial cleanup of github workflows * only run pr-label workflow on push to master * move docker ci/release summaries to scripts * add XS label for PR's under 2 lines * draft test job for Docker CI * fix & activate Docker CI test job * add debug step to docker CI * fix Docker CI test container env * Docker CI build matrix * fixup build summaries * fix pipes in summary * optimize Dockerfile for layer caching * more markdown escaping * add gha cache scopes * add Docker CI cache clean workflow |