Thin Caller & Reusable Workflow

A service repo does not contain deploy logic. It contains a thin caller — a small GitHub Actions workflow that invokes the reusable workflow_call in the ops repo. All the real work happens in the reusable workflow and the orchestrator. You don't write the caller by hand — foundry generate callers emits it from the central platform.json.

The reusable workflow

The ops repo's .github/workflows/deploy.yml is a reusable workflow. Its inputs:

What it does

1. Checks out the caller repo.
2. Mints a short-lived GitHub App token scoped to read the ops repo.
3. Checks out the ops repo (manifest + orchestrator).
4. Reads platform.json to resolve the service's AWS roleArn and region.
5. Sets up Node + corepack + OpenTofu.
6. Configures AWS credentials via OIDC (assumes the resolved role — no long-lived keys).
7. Runs the orchestrator against the checked-out caller repo.

The generated caller

For a service web at path app on branch main, foundry generate callers writes .github/workflows/deploy.yml:

name: "Deploy: web"

# Thin caller - generated by `foundry generate callers` from the central
# platform.json. The ops repo owns the pipeline; this repo names the service.

on:
  push:
    branches: [main]
    paths: ['app/**', '.github/workflows/deploy.yml']
  workflow_dispatch:

concurrency:
  group: foundry-deploy-web-${{ github.ref }}
  cancel-in-progress: false

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    uses: your-org/your-ops-repo/.github/workflows/deploy.yml@main
    with:
      service: web
      environment: prod
    secrets: inherit

• Trigger — push to the service's branch (from its environments override), path-scoped to its subdir when it has one, plus workflow_dispatch.
• uses — the reusable ref is derived from the manifest (<org>/<ops-repo>/.github/workflows/deploy.yml@<ref>), not hard-coded to one org.
• secrets: inherit — forwards the org-level secrets (the GitHub App credentials) the reusable workflow needs.
• File name — deploy.yml for a repo's only orchestrated service, or deploy-<service>.yml when a repo has several.

No deploy steps, no AWS wiring, no strategy logic live in the service repo.