Cross Repo Automation: How to Automate Workflows Across Repositories

Your backend API ships a breaking change. The frontend needs an update. The shared library needs a version bump. The infrastructure repo needs a config tweak. And someone has to coordinate all four pull requests manually, hoping nothing falls through the cracks.

This is the daily reality for teams running microservices or multi-repository architectures. As codebases are split across repos for better separation of concerns, the coordination overhead grows. Cross-repo automation solves this by letting you trigger workflows, synchronize changes, and coordinate deployments across repository boundaries without manual intervention.

This guide covers the patterns, tools, and implementation strategies for automating work across repositories. You'll learn how GitHub Actions handles cross-repo triggering with repository dispatch events and reusable workflows, how to manage permissions and secrets securely, and how coding agents are emerging as a new approach to cross-repo coordination that goes beyond traditional CI/CD pipelines.

What Is Cross-Repo Automation?

Cross-repo automation is any workflow that spans two or more repositories without requiring a developer to manually trigger each step. Instead of a person opening a PR in Repo A, waiting for it to merge, then opening a related PR in Repo B, the automation handles the chain of events programmatically.

In practice, this might look like a GitHub Actions workflow in your API repository that triggers integration tests in your frontend repository after each successful deploy. Or it might be a coding agent that receives a task like "update the authentication flow" and opens coordinated PRs across frontend, backend, and shared library repos in one operation.

Platforms like Tembo take this approach, where a single task can span multiple repositories with linked PRs that include context about how changes in one repo affect the others.

The core idea is the same regardless of implementation: remove the human bottleneck from multi-repo coordination.

Why Teams Need Multi-Repository Automation

Most engineering organizations don't start with a multi-repo problem. They start with a monorepo or a small handful of services. The automation challenge shows up when the codebase splits.

Microservices architectures are the most common driver. Each service gets its own repo for independent deployment, but changes frequently span service boundaries. An API schema change in one service requires client updates in three others.

Shared libraries and packages create another pain point. When a core library publishes a new version, every downstream repo needs to update its dependency. Without automation, these updates sit in a backlog for weeks.

Platform teams maintaining infrastructure-as-code repos face the same issue. A Terraform module update in the infrastructure repo needs to trigger plan-and-apply workflows in every environment repo that uses it.

The manual approach to these problems doesn't scale. A team managing 5 repos can coordinate over Slack. A team managing 50 cannot.

Common Cross-Repo Automation Use Cases

Dependency updates across repos. When a shared package publishes a new version, automatically open PRs in all downstream repos to update the dependency. This is one of the most common starting points for cross-repo automation because the alternative is forgetting to update and discovering the incompatibility in production.

Cross-service integration testing. After deploying Service A, trigger integration tests that validate Service A's contract with Services B and C. This catches breaking changes before they propagate.

Synchronized releases. When multiple repos need to release together (frontend v2.1 requires backend v3.0), automation can coordinate the release sequence, run pre-release checks across all repos, and tag releases in the correct order.

Cross-repo code changes. Renaming an API endpoint, updating an authentication flow, or migrating a database schema often requires changes in multiple repos simultaneously. Coding agents like Tembo handle this by executing a single task across all affected repositories, generating coordinated PRs that reviewers can evaluate together rather than in isolation.

Cross-Repo Automation Patterns and Approaches

There is no single way to automate across repos. The right pattern depends on your CI/CD platform, the complexity of your workflows, and whether you need event-driven triggers or scheduled coordination.

Repository Dispatch Events

Repository dispatch is GitHub Actions' native mechanism for triggering workflows in one repo from another. You send an API call to the target repo, and it fires a workflow configured to listen for that event type.

Here's how it works. In the target repo, you define a workflow that listens for dispatch events:

# target-repo/.github/workflows/integration-tests.yml
name: Run Integration Tests
on:
  repository_dispatch:
    types:
      - api-deployed
      - schema-updated

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests against new API
        run: npm run test:integration
        env:
          API_VERSION: ${{ github.event.client_payload.version }}

In the source repo, you trigger it after a successful deployment:

# source-repo/.github/workflows/deploy.yml
name: Deploy and Notify
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy API
        run: ./deploy.sh
      - name: Trigger integration tests in frontend repo
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.CROSS_REPO_PAT }}
          script: |
            await github.rest.repos.createDispatchEvent({
              owner: 'your-org',
              repo: 'frontend-app',
              event_type: 'api-deployed',
              client_payload: {
                version: '${{ github.sha }}',
                environment: 'production'
              }
            });

The client_payload field passes arbitrary JSON data (commit SHA, version numbers, environment names) to the target workflow, giving it the context it needs to run the right tests or deploy the right version.

Workflow Dispatch and Reusable Workflows

Reusable workflows solve a different problem: duplication. If five repos all run the same linting, testing, and deployment steps, you can define those steps once in a shared workflow repo and call them from everywhere.

# shared-workflows/.github/workflows/standard-deploy.yml
name: Standard Deployment
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
      service-name:
        required: true
        type: string
    secrets:
      DEPLOY_TOKEN:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy ${{ inputs.service-name }} to ${{ inputs.environment }}
        run: ./deploy.sh --env ${{ inputs.environment }}
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Any repo in your org can then call this shared workflow:

# service-repo/.github/workflows/deploy.yml
name: Deploy Service
on:
  push:
    branches: [main]

jobs:
  deploy-staging:
    uses: your-org/shared-workflows/.github/workflows/standard-deploy.yml@main
    with:
      environment: staging
      service-name: user-service
    secrets:
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Dispatch is for event-driven communication between repos ("something happened in Repo A, react in Repo B"). Reusable workflows are for DRY configuration ("every repo deploys the same way, define it once"). Most cross-repo setups use both.

Mono-Repo vs. Multi-Repo Automation Strategies

Mono-repos sidestep cross-repo automation entirely by keeping everything in one repository. Tools like Nx, Turborepo, and Bazel handle selective builds and tests within the monorepo, running only what changed.

Multi-repo architectures trade that simplicity for better isolation. Each team owns its repo, deploys independently, and sets its own release cadence. The cost is coordination overhead, which is exactly what cross-repo automation addresses.

The hybrid approach is increasingly common: teams keep tightly coupled services in a monorepo but use separate repos for independent services, infrastructure, and shared libraries. This requires cross-repo automation for the inter-repo boundaries while using monorepo tooling within each repo.

Cross-Repo PR and Issue Synchronization

Beyond CI/CD triggers, many teams need to synchronize pull requests and issues across repos. When a breaking change in Repo A requires a follow-up change in Repo B, you want those PRs linked so reviewers see the full picture.

GitHub's native linking (mentioning a PR URL in another PR) provides basic visibility, but it doesn't enforce coordination. More advanced patterns include creating "meta-issues" that track related PRs across repos, or using Tembo's coordinated PR approach, where a single task generates linked PRs across all affected repos with descriptions that explain the cross-repo implications.

Some teams build custom GitHub Actions that automatically open companion PRs in dependent repos when a PR is merged. For example, merging a schema change PR in the API repo triggers a workflow that opens PRs in all client repos with the updated schema types.

How to Set Up Cross-Repo Automation with GitHub Actions

GitHub Actions is the most accessible starting point for cross-repo automation because most teams already use it for CI/CD. Here's how to configure it step by step.

Step-by-Step: Triggering Workflows Across Repos

Step 1: Create a Personal Access Token (PAT) or fine-grained token. The default GITHUB_TOKEN only has permissions within the current repo. To trigger workflows in other repos, you need a token with broader access. Create a fine-grained PAT with contents: write permission on the target repos.

Step 2: Store the token as a repository secret. In the source repo, go to Settings > Secrets and variables > Actions. Add the PAT as a secret (e.g., CROSS_REPO_PAT).

Step 3: Add a repository_dispatch trigger to the target repo. Create a workflow file in the target repo that listens for your custom event type (shown in the dispatch example above).

Step 4: Add a dispatch step to the source repo's workflow. After the relevant job completes (deploy, test, build), add a step that sends the dispatch event using actions/github-script or a direct API call.

Step 5: Test the full chain. Push a change to the source repo and verify that the target repo's workflow triggers. Check the Actions tab in both repos to confirm the event was received and the workflow ran.

Managing Permissions and Secrets

Cross-repo tokens are the biggest security consideration. A PAT with access to multiple repos is a high-value target. Limit the scope:

• Use fine-grained PATs instead of classic tokens. Fine-grained PATs let you specify exactly which repos and permissions the token has.
• Scope to the minimum permission needed. If you only need to trigger workflows, contents: write on the target repo is sufficient. Don't grant admin access.
• Rotate tokens regularly. Set a reminder to regenerate PATs every 90 days.
• Use GitHub's OIDC for cloud providers. If your cross-repo workflow deploys to AWS, GCP, or Azure, use OpenID Connect instead of storing cloud credentials as secrets.

For organizations using GitHub Enterprise, GitHub Apps provide a better alternative to PATs. A GitHub App can be installed on specific repos with fine-grained permissions, and its token automatically scopes to only those repos.

Handling Dependencies Between Repositories

The hardest part of cross-repo automation is managing execution order when repos depend on each other. If Service B depends on Service A's API, you need Service A to deploy before Service B runs its integration tests.

Pattern 1: Sequential dispatch chains. Repo A deploys and dispatches to Repo B. Repo B tests and dispatches to Repo C. This works for linear dependencies but creates a fragile chain where one failure blocks everything downstream.

Pattern 2: Fan-out with status aggregation. Repo A dispatches to Repos B, C, and D simultaneously. A separate "coordinator" workflow polls the status of all three and proceeds only when all pass. This is faster but more complex to implement.

Pattern 3: Agent-based coordination. Instead of building dispatch chains, you describe the task and let a coding agent figure out the dependency order. Tembo's async execution model handles this by working across repos in parallel, generating PRs that account for inter-repo dependencies. The agent understands which changes need to land first and structures the PRs accordingly.

Tools for Cross-Repository Automation

Tool	Platform	Key Cross-Repo Feature	Best For
Tembo	Any (GitHub integration)	Agent-based coordinated PRs across repos	Complex code changes spanning multiple repos
GitHub Actions	GitHub	Repository dispatch, reusable workflows	Teams already on GitHub needing CI/CD triggers
GitLab CI/CD	GitLab	Multi-project pipelines with trigger keyword	GitLab-native teams wanting built-in orchestration
Jenkins	Self-hosted	Pipeline libraries, parameterized triggers	Enterprise teams with existing Jenkins infrastructure
Terraform	Cloud agnostic	Module dependencies across state files	Infrastructure-as-code across repo boundaries
Nx / Turborepo	Monorepo	Affected-based task execution	Teams considering monorepo consolidation
Renovate / Dependabot	GitHub/GitLab	Automated dependency PRs across repos	Dependency updates at scale

Coding Agents for Cross-Repo Tasks

Coding agents represent a fundamentally different approach to cross-repo automation. Instead of defining explicit workflow triggers and dispatch chains, you describe what needs to happen, and the agent executes it across repos.

Tembo operates as a background coding agent that integrates into your existing dev stack. When a task requires changes across multiple repos, Tembo's agents work in parallel across all affected repositories, each in an isolated sandbox. The result is a set of coordinated PRs that link to each other and include context about cross-repo implications.

This approach works well for tasks that are hard to express as CI/CD triggers: "update the authentication flow across all services," "migrate from library v2 to v3 in every repo that uses it," or "fix the error handling pattern that Sentry flagged across three repos." These tasks require understanding code context, not just running predefined steps.

Tembo's automations can also trigger these cross-repo tasks on schedules (hourly, daily, weekly) or in response to events like Sentry errors, Linear issues, or Slack mentions, bridging the gap between traditional CI/CD triggers and agent-based execution.

GitHub Actions (Native Cross-Repo Support)

GitHub Actions provides the most direct path to cross-repo automation for teams already on GitHub. Repository dispatch events, reusable workflows, and workflow_call give you the primitives. The ecosystem of community actions (like actions/github-script) fills in the gaps.

Strengths: Native integration, no additional infrastructure, a large community action marketplace, fine-grained permissions with OIDC, and fine-grained PATs.

Limitations: Complex multi-repo orchestration requires custom scripting. No built-in dependency graph across repos. Status aggregation across repos requires a custom implementation.

GitLab CI/CD Multi-Project Pipelines

GitLab's trigger keyword lets you start pipelines in other projects directly from your .gitlab-ci.yml:

trigger-frontend-tests:  
  stage: post-deploy  
  trigger:  
    project: my-group/frontend-app  
    branch: main  
    strategy: depend

The strategy: depend option means the triggering pipeline waits for the downstream pipeline to complete, making dependency chains straightforward.

Strengths: Built-in multi-project pipeline support, strategy: depend for chaining, parent-child pipeline relationships, native artifact passing between projects.

Limitations: GitLab-only. Migrating from GitHub means rebuilding all workflows.

Best Practices for Cross-Repo Automation

Keep Workflows DRY with Reusable Components

Duplicated workflow definitions across repos become a maintenance nightmare. When you need to update a deployment step, you shouldn't be editing 15 workflow files.

Use reusable workflows for shared CI/CD steps. Create a central shared-workflows repo in your org. Define your standard build, test, lint, and deploy workflows there. Every service repo calls these shared workflows instead of duplicating the YAML. When the deployment process changes, you update one file.

Use composite actions for smaller, reusable steps. If a full reusable workflow is overkill, composite actions let you bundle a sequence of steps into a single action that any workflow can use.

Version your shared workflows. Reference them with a tag or SHA (@v1.2.0 or @abc123) rather than @main. This prevents an update to the shared workflow from breaking all downstream repos simultaneously.

Implement Proper Error Handling and Rollbacks

Cross-repo automation multiplies the blast radius of failures. A bug in your dispatch logic can trigger unintended deployments across multiple repos simultaneously.

Always include failure notifications. When a cross-repo workflow fails, the team that owns the source repo and the team that owns the target repo both need to know. Use Slack notifications or GitHub issue creation on failure.

Build in rollback triggers. If a deployment in Repo A triggers integration tests in Repo B and those tests fail, you need a way to roll back Repo A's deployment automatically. This is where strategy: depend (GitLab) or status-check workflows (GitHub) become critical.

Use if: failure() conditions in GitHub Actions to run cleanup steps when a cross-repo chain breaks. This prevents partial deployments where Repo A is deployed, but Repo B's tests revealed an issue.

Monitor and Audit Cross-Repo Pipelines

Visibility is the most underrated aspect of cross-repo automation. When a workflow chain spans five repos, diagnosing "why did the deployment fail?" requires tracing across multiple Actions runs.

Centralize your workflow logs. Send key workflow events (start, completion, failure) to a shared observability platform (Datadog, Grafana, or even a dedicated Slack channel). Include the source repo, target repo, event type, and commit SHA in every log entry.

Track cross-repo workflow durations. Measure the end-to-end time from "commit pushed to Repo A" to "all downstream workflows complete." This metric reveals bottlenecks in your automation chain.

Audit token usage. Regularly review which PATs and GitHub Apps have cross-repo permissions. Revoke any tokens that are no longer needed. GitHub's security audit log shows which tokens accessed which repos.

Conclusion

Cross-repo automation is no longer optional for teams managing multiple repositories. GitHub Actions provides the foundational primitives through repository dispatch events and reusable workflows, GitLab offers built-in multi-project pipelines, and coding agents like Tembo add a layer of intelligence that handles complex, context-dependent changes across repo boundaries.

The practical path forward is to start small. Pick one cross-repo workflow that your team currently does manually (dependency updates, integration test triggering, or synchronized deployments) and automate it with repository dispatch. Once that's running reliably, expand to reusable workflows for DRY configuration, and consider agent-based coordination for tasks that require understanding code context rather than running predefined steps.

For teams ready to explore how coding agents handle cross-repo tasks, Tembo's free tier lets you run agents across your repositories and see coordinated PRs in action.