Skip to main content

​
Multi-Repo Setup and Configuration

What is a multi-repo project? What’s the benefit?

A multi-repo (polyrepo) project spreads the product across several Git repositories instead of a single monorepo, which gives each service, library, or infrastructure module its own pipelines and permissions. Enterprises lean on it for autonomy: teams ship on their own cadence, guard access per repo, and even share specific repos with vendors or customers without exposing the rest of the codebase.

Watch video

Why do coding agents struggle to work with multiple repos?

IDE copilots typically ingest only the repo that’s open in the editor. Even multi-root workspaces inherit config (linters, auth, launch files) that assume a single repo, so agents end up blind to adjacent services. Without those sibling repos, they hallucinate APIs, miss cross-repo contracts, and ship brittle changes because they cannot inspect or test the surrounding code.

What’s the Zencoder multi-repo tool?

It’s an indexing system in the dashboard that ingests any GitHub, GitLab, or Bitbucket repo you connect via a scoped token. Once indexed, Zencoder keeps a read-only snapshot plus metadata (owners, last index time, auto- reindex toggle), and agents with the multi-repo tool can list, open, and read those repos even if they’re not the one currently open in the IDE.

How to configure the Zencoder multi-repo tool?

In the web dashboard, start on Connections to add GitHub/GitLab/Bitbucket access with a personal access token that scopes exactly which repos the agent should read. Then switch to Repositories, add repos one by one, decide whether they auto-reindex on changes, and assign which teammates can use each repo through the tool. The same page shows indexing status so you can trigger manual refreshes later.

How to use the multi-repo tool?

Enable the tool on any agent (built-in or custom) and run your normal chat in the IDE. When the agent needs extra context it calls listRepos, jumps into the indexed repo, reads files or docs, and returns to edit the open repo. It’s read-only - changes still land in the workspace you’re editing - but it gives the agent the architectural picture it needs. A quick sanity check is to ask, “What repos can you see through the Multi-Repo tool?” and make sure it lists everything you expect.

Share card via email

​
GitHub-Triggered Autonomous Agents

What are autonomous agents?

They are the same Zencoder agents you run inside the IDE, but deployed as headless workers that live in your CI/CD systems. A trigger from GitHub/GitLab/Bitbucket (or any webhook) wakes them up; they load the repo map, follow their instructions, plan edits, run tests, and publish output without a human steering every step.

Watch video

How can autonomous agents be activated at Zencoder, as an addon?

It’s a paid addon (Core plan or higher). Contact sales via https://meetings.hubspot.com/griffin-kurzius/zencoder-intro and the team will enable the feature for your org, unlocking the dashboard sections for Connections, Repositories, and Autonomous Flows.

How are autonomous agents configured in GitHub/GitLab/Bitbucket?

Each provider follows the same arc: drop our workflow file into the repo, generate a Zencoder client ID/secret plus a platform token with repo + workflow scopes, store them as CI secrets, and register the repo inside Zencoder so the agent can pull code. The workflow then calls your chosen agent whenever the CI event fires. Full checklists live in the configuration guide: https://docs.zencoder.ai/features/autonomous-agents-configuration.

What are use cases of autonomous agents in GitHub?

They become programmable teammates inside CI: auto-review every pull request, fix reviewer comments, enforce internationalization, keep dependencies fresh, or assemble release notes the moment a branch or tag appears. Because workflows can target any custom agent, all your org-specific prompts carry over from the IDE into GitHub Actions.

Share card via email

​
Jira-Triggered Autonomous Agents

What is the additional configuration needed to trigger from Jira?

Jira triggers use the webhook flavor of autonomous flows. You place the webhook workflow file in your repo, create an autonomous flow in the dashboard (which generates a webhook URL + secret), and then author a Jira Automation rule that POSTs that payload with the secret. It’s a few more steps than a pure CI trigger, so keep the configuration guide handy when wiring the Jira form: https://docs.zencoder.ai/features/autonomous-agents-configuration.

Watch video

How to monitor the autonomous agents triggered from Jira?

Check three surfaces: the Jira Automation rule history (to confirm the webhook fired), your CI provider’s run logs (GitHub/GitLab/Bitbucket show the workflow execution), and the Autonomous Flows list in Zencoder, which records each run’s status and output. Together they confirm the webhook arrived, the workflow ran, and the agent wrapped up successfully.

Where else can autonomous agents be triggered from?

Anywhere that can call a webhook or emit a CI event: Linear, Zendesk, custom internal tools, cron jobs, or other business systems can hit the Zencoder webhook endpoint, while GitHub, GitLab, and Bitbucket platform triggers fire on pushes, pull requests, or scheduled workflows. If a system can send HTTP, it can wake an autonomous agent.

Share card via email