Builds

Builds turn source code into container images that deployments can run. ZopDay builds from a connected git integration (GitHub today). The actual docker build runs on a GitHub Actions workflow: no in-cluster Kaniko, no shared build farm, no build queue contention between tenants.

Pick a Repository & Branch

Repos and branches are read live through the connected GitHub App token (or PAT for self-hosted). ZopDay does not cache the user’s repo list across sessions.

{
  "data": [
    {
      "integrationID": "int_github_001",
      "owner": "acme",
      "repo": "checkout",
      "defaultBranch": "main",
      "private": true
    }
  ]
}

Analyze a Repository

Before kicking off a build, the wizard runs an analyzer that inspects the repo and proposes deployment defaults, language, framework, port, health probe path, and (when present) a Dockerfile. Stack detection is powered by Railpack, so most repos can be deployed without ever opening a config file.

curl -X POST https://api.zop.dev/analyze \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "integrationID": "int_github_001",
    "owner": "acme",
    "repo": "checkout",
    "branch": "main",
    "rootPath": "."
  }'

{
  "data": {
    "language": "go",
    "framework": "gofr",
    "suggestedPort": 8080,
    "suggestedHealthPath": "/health",
    "dockerfile": "Dockerfile",
    "buildContext": ".",
    "needsBuild": true,
    "warnings": []
  }
}

Note: /analyze is the wizard-time analyzer (pre-create). For re-analyzing an existing deployment, see POST /deployments/{id}/analyze on the Deployments page.

How a Build Runs

1. You create a deployment (or push to a branch with auto-deploy on). ZopDay records a new revision and queues a build.
2. The repository is cloned and a GitHub Actions build workflow is dispatched with a callback URL and a signed callback token.
3. The workflow runs Railpack (if there’s no Dockerfile) or a plain docker build, then pushes the image to your registry.
4. The workflow reports the result to /build-callbacks/{revisionID}. ZopDay verifies the token, records the image ref on the revision, and queues the rollout.
5. ZopDay mints short-lived cluster credentials from the cloud account and applies a Helm release to the target cluster’s namespace.

Build Callback

The build workflow reports back over a gateway path that does not take a session token. Instead, the request body carries a signed, short-lived callback JWT issued for that revision. This is an internal contract between ZopDay and its build runner; you do not need to call it yourself.

{
  "callbackJwt": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<payload>.<sig>",
  "event": "status",
  "status": "succeeded",
  "imageRef": "ghcr.io/acme/checkout:abc1234",
  "commitSha": "abc1234",
  "port": 8080
}

See Deployments for revision endpoints, and Webhooks for how the GitHub push event kicks the build pipeline off in the first place.