Skip to content

Tale v0.5.92

Choose a tag to compare

View all tags
@github-actions github-actions released this 26 Oct 23:23
v0.5.92
53d1fdb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

  • Keep a project's agents busy with dispatch. A project's new Dispatch tab starts its ready tasks on the agents of its pool as soon as one is free, up to the runs the pool and each agent may hold, in the order of the board's columns, priorities and positions, asking the sandbox host before each start. Standing roles start an agent on its own task on a schedule, each occurrence decided once, and gates hold the work they govern while a signal from outside says so, such as a full CI queue (POST /api/v1/projects/{id}/dispatch/gates/{key}). The tab says why each agent of the pool is idle; administrators edit the dispatch there, or declare it as the managed resource project-dispatch with the tale CLI. The CLI asks Tale whether a declared dispatch would be saved before it writes anything of the declaration, so a dispatch Tale would refuse leaves the rest of the declaration unapplied (#4987, #4995, #4945).
  • Run one agent on hundreds of tasks. A dispatch may hold up to 500 runs at once and keep one agent of its pool on up to 500 of them, so one coding agent can work a large board on hundreds of workers. Without a spacing, a pass starts work for up to two minutes and then asks for the next pass at once. The Dispatch tab counts each agent's runs (running, queued and waiting by reason) and lists its 50 oldest (#4998).
  • One project's dispatch can serve other projects' boards. A central project's pool and its reviewers can work the boards of other projects of the organization, such as one board per product or client. Adding a board takes the right to edit it, and every pass checks that right again for whoever saved the dispatch last: a board that is gone, archived or out of that right is skipped, and the tab says why. A run a person starts on a served board gets the agent's secrets, credentials and standing workspace only when that person may edit both projects. Boards and reviewers are set through the settings tools or the tale CLI; the app's editor shows them and keeps them (#5001).
  • A model at capacity makes the runs of project agents' tasks wait instead of failing them. When a provider refuses a run because its model is at capacity, every task run of the organization on that model waits as Waiting for model capacity and holds no worker; after 1, 2, 4, 8 and then 15 minutes one run tries first and the others follow once it works. Waiting spends no automatic retry, so an agent's own task no longer pauses itself after three refusals. A model that stays at capacity for twelve hours is no longer waited for. When the model answers again, the waiting runs wake in waves 15 seconds apart that double up to a sixteenth of the waiters, so 256 or even 500 waiting runs have all started within five minutes, and for five minutes dispatch starts new work on that model at the same pace. For task runs this replaces the one-minute retry floor of v0.5.91, which an automation's agent step keeps (#4987, #4998).
  • Automation templates. Every automation Tale ships is a template in one catalog under Create automation › From a template: cards with the product's logo, a preview of how it works, what it changes and never does, when it runs and what it needs, its workflow drawn read-only, and Use this template, which asks its questions and can create and start the automation in one step. New organizations start without automations; people add the ones they need (#4988).
  • Sync issues, pull requests and security alerts in one step for any number of sources: GitHub issues and pull requests (Renovate's, for example, by their author), a GitHub repository's code scanning, Dependabot and secret scanning alerts as one task per alert from a severity you choose (a secret's value is never read), Forgejo issues and pull requests through the new Forgejo connector, and GlitchTip issues. Each source can label the tasks it creates. A failing source, an issue the tracker refuses or a write the database refuses never stops the others, a rate limit's wait is kept for later runs, and the step fails only when every source failed, or, with failOn: any, when any one did (#4988, #4997).
  • The mail syncs read a mailbox's Inbox, and its Sent folder unless that is turned off, oldest first and each email once. Gmail no longer skips mail when a backlog is larger than one pass or stalls on a burst of mail in one second, a sender's wrong Date header no longer strands later email, and a mailbox's first pass reads back a set number of days, 7 to start with (#4988).
  • Connect a shared Outlook mailbox to the Inbox. An administrator adds an Outlook credential that signs in as an Entra app scoped to that mailbox, or a person with Full Access to it names the mailbox when connecting. The mail sync, triage, drafts and replies then work on that mailbox, and a credential keeps the mailbox it was added with (#5002).
  • The shipped triage, review, digest and webhook automations hold up at production sizes: each caps its batch, the pull request reviewer reviews once per new commit, inbox triage marks a thread only once its draft is left, the task digest lists every task since the last digest exactly once, and a webhook delivery sent again updates its task. A loop step can go on past a failed item (onItemError: continue) (#4988).
  • Give each agent its own repository access. An owner or administrator can pin the GitHub or Forgejo credential a project agent works as and set the name and email its commits carry, so one agent reaches every repository and another only its client's. A pinned agent works only as its pinned credential, never as the default in its place, and agents equipped with Forgejo can now clone from and push to it in their sandbox (#5003).
  • Agents see a task's labels: task_find and task_get answer labels, and a run's brief names the same labels in the same order (#5004).
  • The sandbox host admits work by its pressure, and project agents are told to take a lease before a heavy phase such as an install or a full test run (host_lease_acquire), so heavy phases take turns on a shared Docker host. Idle agent workspaces are reclaimed while the workspaces' disk runs short, and above a size once a policy sets maxWorkspaceGiB (#4987).
  • Login shells in a sandbox session now find node, npm, the agent CLIs and the packages the session installed. The shell tool of the Codex harness runs commands in one, and found none of them before (#5019).
  • Reach other websites through your own proxies. OUTBOUND_PROXY_URLS lists HTTP proxies that every request to another website takes in turn: the website crawler, the chat assistant's web fetch, remote images in emails, video ingestion and everything a sandbox session reaches on the internet. The services a deployment is configured with, such as model providers and connectors, are still reached directly. A proxy that fails is set aside and the request goes once more through the next one; nothing falls back to the server's own address. VIDEO_INGEST_PROXY_URL still gives video ingestion a proxy of its own (#5053).
  • Declare a fleet with the tale CLI. A managed declaration can now create, not only adopt, projects, their labels and agents, standing tasks, agent secrets and connector credentials (createIfMissing: true). Secret values come from TALE_CONFIG_SECRET_* variables and never enter a declaration, plan or receipt, and a declaration file can include others (#5000).
  • Sign a managed deployment's people in through any OpenID Connect provider, such as ZITADEL, with identity.oidc beside or instead of the Entra fields (#5016).
  • Run a managed deployment's sandboxes on an Incus node by declaring sandbox with backend: incus. A deployment switches between Docker and Incus in place, after draining the outgoing sandbox service. Incus sessions can install npm and PyPI packages through the node's caches (SANDBOX_INCUS_NPM_REGISTRY, SANDBOX_INCUS_PYPI_INDEX), and SANDBOX_EGRESS_DENIED_HOSTS stops a package manager from going around them (#5015, #5017).
  • Dependencies move to releases that fix published advisories: dompurify 3.4.17 (a critical advisory), undici 7.30.1, zod 4.6.6, vite 8.1.6, follow-redirects 1.16.1 and Storybook 10.6.2 (#5054).

Upgrade notes

  • From v0.5.91 to v0.5.92 the backend applies migrations 0205, 0206, 0207 and 0209 to 0219 at start; all are additive, and each is safe while the previous image still serves.
  • The API contract moves from 3.44.0 to 3.49.0. It adds the project dispatch read and its gates (3.45.0, with the error codes DISPATCH_GATE_UNKNOWN and DISPATCH_GATE_VALUE_UNJUDGED), the 500-run dispatch limits and each agent's runCounts (3.46.0), tasks synced from GitHub security alerts and Forgejo (3.47.0), a dispatch's sources, reviewers and servedBy (3.48.0), and an agent's connectorCredentials and gitIdentity (3.49.0, with the error codes PROJECT_AGENT_CREDENTIAL_UNKNOWN and PROJECT_AGENT_CREDENTIALS_FORBIDDEN). The settings tools take a project's dispatch (project-dispatch). One change reaches tasks a client made before: a task whose externalSystem is github-security or forgejo now belongs to the issue sync, so its externalState no longer moves it and PUT …/tasks/{taskId}/external-status refuses it (TASK_EXTERNAL_REF_INVALID), where a closed state used to park it at in_review. PUT /api/v1/projects/{id}/agents/{agentId} keeps connectorCredentials and gitIdentity when the body leaves them out; send {} or null to clear them.
  • Update the sandbox service and the sandbox-runtime image with the backend. An older sandbox service keeps working, but the backend then grants no heavy-phase leases and reads no workspace sizes. The runtime image's git credential helper now reads only TALE_GIT_CREDENTIALS, so a new runtime image under an older platform gets no git credential for github.com, and an older runtime image under this platform reaches github.com but not Forgejo. New sandbox settings: SANDBOX_ADMISSION_PRESET (default), SANDBOX_ADMISSION_LOAD_PER_CPU, SANDBOX_ADMISSION_CPU_PSI, SANDBOX_ADMISSION_MEMORY_PSI, SANDBOX_ADMISSION_IO_PSI, SANDBOX_ADMISSION_RECOVER (0.5), SANDBOX_HEAVY_LEASES_MAX (2) and SANDBOX_HEAVY_MIN_FREE_DISK (20g). Kubernetes, Incus and remote Docker daemons grant no leases, and agents work without them. A dispatch judged by the conservative admission preset, set as its Sandbox host or by SANDBOX_ADMISSION_PRESET=conservative, starts no work where the host cannot be judged: under an older sandbox service, and on Kubernetes, Incus or a remote Docker daemon.
  • Reclaiming idle workspaces on disk pressure is on by default: an agent workspace idle for 24 hours may be deleted while the workspaces' disk is short. Set reclaimOnDiskPressure: false in the sandbox_workspaces policy, or raise reclaimMinIdleHours, before upgrading if you keep large idle workspaces on purpose; pinned workspaces and those under a legal hold are never reclaimed.
  • New organizations get no automations, and tale migrate adds none: it adds the configuration files an organization is missing and the starter project to one without a project. Organizations keep the automations they have. The GitHub and GlitchTip import automations leave the catalog for Sync GitHub issues and Sync GlitchTip issues; copies already installed keep working.
  • Mail syncs installed before this release keep their documents: Gmail and Outlook copies read Sent only once edited, and an IMAP copy's limit now covers the Inbox and Sent together. Their positions carry over; a position dated in the future restarts at the seven-day window, and email read twice is stored once.
  • A GlitchTip sync source that names a credential now keeps a position of its own, so its next run reads that source once more from the oldest issue; no task is duplicated.
  • Dispatch is off until a project administrator sets it up; automations that start agents keep working. Once it is on, tale_backend_dispatch_last_pass_timestamp_seconds{project} tells when each project's dispatch last completed a pass, and the Prometheus guide's alert rules include one for a dispatch that stops (TaleDispatchStopped).
  • Project instructions now reach task agents: every turn of a task agent, retries included, opens with its project's current instructions, between the organization's custom instructions and the agent's own. Before, only a project's chats read them, so check instructions written for chat alone before upgrading. A turn whose project or task cannot be read does not start, and is retried like any failed start.
  • During a rolling deploy, an older worker that takes a run of a template made by this release can fail it, because it does not know onItemError, task.sync_issues or the automation connector. Deployments that drain before they switch colours are not affected.
  • A generic OIDC or OAuth2 sign-in connection that maps the email claim (claimMappings.email) now refuses a person whose provider answer lacks that claim; before, it fell back to email and then preferred_username. Before you upgrade, confirm that your provider sends the mapped claim for everyone.
  • For every OAuth connector, a token endpoint that answers 5xx or 429 during a refresh no longer marks the credential for reauthentication: that call fails with the retryable CREDENTIAL_REFRESH_FAILED, and the next call refreshes again. A connection starts only from Tale: a Connect link followed from another site is refused (cross_site_start).
  • Upgrade the tale CLI with the platform. This CLI declares a project's dispatch (project-dispatch, with its sources and reviewers), the new managed kinds (project, project-label, project-agent, task, agent-secret, connector-credential), identity.oidc and an Incus sandbox; an older platform answers 404 at plan for the new kinds, before anything is written. Declaring a new secret or rotating its value changes the backend's environment, so it needs a full deployment, not --configuration-only. tale deploy now removes SANDBOX_INCUS_* and SANDBOX_BACKEND=incus from a managed deployment's .env unless its specification declares them.
  • New optional settings, none of which changes anything until it is set: OUTBOUND_PROXY_URLS (read by the backend roles and sandbox-egress; recreate both after a change), CONNECTOR_OAUTH_<SLUG>_TENANT_ID (a single-tenant Microsoft app), SANDBOX_INCUS_NPM_REGISTRY, SANDBOX_INCUS_PYPI_INDEX and SANDBOX_EGRESS_DENIED_HOSTS (Incus registry caches: roll the runtime image and the sandbox service together, and set the deny-list last), and the TALE_CONFIG_SECRET_ prefix for the secrets a managed declaration reads.
  • The release publishes eleven images: the tale-ai-gateway image is gone. No deployment tale deploy makes ran it, and subscription accounts work through a broker you operate.

API contract changes

The contract moved from 3.44.0 to 3.49.0 (161 → 163 operations). Read the API reference's versioning section before upgrading a pinned client.

Added operations:

  • GET /api/v1/projects/{id}/dispatch
  • POST /api/v1/projects/{id}/dispatch/gates/{key}

Removed operations: none.

Changelog

3.49.0 — 2026-10-15: a project agent carries its own repository access. ProjectAgent answers connectorCredentials (a connector slug to the name of the organization credential the agent acts as; {} when it pins none) and gitIdentity ({name, email} its commits carry, or null), and POST/PUT /api/v1/projects/{id}/agents… take both. A pin must name a credential the organization holds for that connector (400 PROJECT_AGENT_CREDENTIAL_UNKNOWN, the pins under data.connectorCredentials), and only an organization admin may change the pins (403 PROJECT_AGENT_CREDENTIALS_FORBIDDEN). Only a connector that opens a git host — GitHub, Forgejo — takes a pin; one on any other connector is refused with the same 400. A PUT that omits either field keeps what is stored — unlike the other optional fields, since dropping a pin would widen the agent to the connector's default — and {} / null clear them. An equipped pinned connector hands the agent's sandbox the pinned credential's git access instead of the default's, and the agent's connector calls through the sandbox bridge act as it too; a pin whose credential is gone hands it nothing and fails those calls. The MCP list_connectors tool names that host as gitHost.

What's Changed

Full Changelog: v0.5.91...v0.5.92

Contributors

yannickmonney
Assets 8
Loading