Skip to main content
Git deploys makes a linked repository the source of truth for your Plays. It reads Play code from one directory in that repository, validates pull requests, and deploys production changes from one branch. You do not need a GitHub Actions workflow or a Deepline API key in GitHub.
Git deploys is in beta. For access, contact the Deepline team through the support button on your dashboard.

​
How a linked repository works

A linked repository has four settings: Each production push creates one deployment for the linked repository at that commit. Deepline reads the manifest, then discovers the matching *.play.ts files below the root directory. Deepline validates every changed Play in that deployment before changing any live revision. If one validation fails, the previous live revisions stay in place. If validation succeeds, all changed Plays are promoted together. Unchanged Plays are skipped by content hash. This makes a production branch push the only way that link changes live Plays. Pushes to other branches are ignored unless they are part of a pull request.

​
Before you start

You need:
  • workspace owner or admin access
  • permission to install a GitHub App for the repository
  • at least one *.play.ts file in the repository
Anyone who can push to the production branch can change the Plays that run in this workspace.

​
Connect GitHub on the Web

In Deepline, open Deploys and select Connect GitHub: Deploys page with the Connect GitHub button If Link a repository appears instead, GitHub is already connected. Select it and continue with Link a repository.
1

Install the app

On GitHub, install the Deepline GitHub App on the account that owns the repository. If an organization owns it, choose that organization.
2

Choose repository access

Grant access to all repositories or select specific repositories.
GitHub returns you to the repository-linking dialog after installation. In the repository-linking dialog, select the repository and production branch. Set a root directory for a monorepo or a different manifest filename if needed. Pull-request checks are enabled by default. Confirm the link. Linking does not deploy existing commits; the next push to the production branch starts a deployment. The same repository can have separate links for different root directories or workspaces. Each link has its own settings and deployment history.

​
CLI quickstart

Sign in to the workspace with deepline auth register, then:
Replace acme/growth with a repository from deepline git repos and DEPLOYMENT_ID with an ID from the deployment list. Use --root-dir packages/growth for a monorepo, --manifest <filename> for another manifest, or --no-pr-checks to disable pull-request checks. Add --json for machine-readable results.

​
Select Plays with a manifest

Without a deepline.json file, Deepline finds every *.play.ts file under the linked root directory. Add a manifest when you need narrower matching:
Manifest globs are relative to the linked root directory. They cannot be absolute or contain ... The manifest describes the complete Play set for a link. A production deployment evaluates that set together, but promotes only Plays whose content changed. A deployment supports at most 100 Play files. Each Play can import files from its own directory or a child directory. An import cannot escape the Play’s directory. Keep provider credentials and Play secrets in Deepline. Do not commit credentials, customer data, or live provider responses.

​
Validate pull requests

Open a pull request from a branch in the linked repository. Deepline adds a Deepline Plays check run. A successful check:
  • builds and validates the changed Plays
  • registers changed Plays as draft revisions
  • leaves every live revision unchanged
Draft pull requests do not build. Mark a draft ready for review to start its first build. Fork pull requests do not receive a Deepline build or check in the current version. Use the deployment details to copy a registered pull-request revision ID and run it:

​
Deploy to production

Merge the pull request or push directly to the configured production branch. Deepline creates a production deployment for the pushed commit. Watch deployments on the dashboard under Deploys, or use:
Inspect one deployment:
The deployment can finish as succeeded, failed, superseded, cancelled, or reconcile_failed. Use deepline git cancel DEPLOYMENT_ID to cancel a queued or running deployment.

​
Roll back a deployment

Revert the source commit and push the revert to the production branch. The revert creates a new, auditable deployment. The dashboard lets you change the same settings, enable or disable pull-request checks, pause a link, or unlink it. The CLI provides the same controls. Pause new deployments:
Resume deployments:
Update a branch, root directory, manifest, or pull-request checks with deepline git set. Run deepline git set --help for the complete options. Unlink the repository:
Pausing or unlinking stops new deployments. It does not stop or archive live Plays.

​
Current limits

  • Git deploys supports GitHub.com through the Deepline GitHub App.
  • Fork pull requests are ignored.
  • Non-production branch pushes without a pull request are ignored.
  • Build compute is metered and deployment details show the build duration.
If you cannot install the GitHub App, use GitHub Actions instead.