Skip to main content
Human guide: task steps and agent prompt → Git deploys builds committed Play files from a linked GitHub.com repository. Ready pull requests register draft revisions; pushes to the production branch promote changed Plays. You need no Actions workflow or Deepline key in GitHub. Git deploys is in beta and requires workspace enablement. Request access through the support button on your Deepline dashboard. Use Deploy with GitHub Actions for restricted organizations or GitHub Enterprise Server.

​
Before you start

You need:
  • Workspace owner or admin access.
  • Permission to install the Deepline GitHub App for the repository.
  • Committed *.play.ts files for this Play deployment.
  • The intended workspace, production branch, root directory, and file selection.
Keep provider credentials and active Play secrets in Deepline. Keep credentials, customer data, and live provider responses out of the repository. Anyone who can push to the production branch can change the Plays in this workspace. The App requests repository contents, metadata, and pull-request read access, plus check-run write access. Its registration also requests email read access for GitHub sign-in.
  1. Open Deploys in Deepline.
  2. Select Connect GitHub.
  3. Install the App on the account or organization that owns the repository.
  4. Grant access to the selected repositories.
Deploys page with the Connect GitHub button GitHub returns you to the repository-linking dialog. If GitHub is already connected, select Link a repository instead.
  1. Select the repository in that dialog.
  2. Set the production branch, root directory, and manifest filename.
  3. Confirm the link.
  4. Check the saved settings under Repositories.
Linking does not deploy existing commits. The next production-branch push starts a deployment. Other branch pushes need a pull request to trigger validation. A repository can have links for different root directories or manifest paths. Within one GitHub installation, an active repository/root/manifest target cannot be linked twice, including across workspaces. Review overlap warnings before confirming another target.

​
Select the complete file set

Without the default manifest, discovery includes **/*.play.ts and **/*.monitor.json below the linked root. To select Plays without Monitor files, commit this deepline.json:
Globs are relative to the linked root. They cannot be absolute or contain ... A missing explicitly configured custom manifest fails the deployment. Each deployment supports at most 100 Play files. A Play’s imports must stay within its directory or child directories. To deploy Monitor files, select their globs and follow Monitor file deployment. Monitor access, admission, and Deepline-credit rules still apply. Production deployments apply Monitor definitions through Monitor Jobs. Provider changes can remain after a later failure; Play promotion does not roll them back. Stopped Monitors stay stopped. Removing a file or changing its glob does not delete an existing Monitor. Inspect Monitor Jobs before retrying or retiring it.

​
Validate a pull request

Open a ready pull request from a branch in the linked repository. Deepline creates a Deepline Plays check. Multiple deployment targets can add workspace/root details to its name. A successful check validates changed Plays and registers draft revisions. It leaves live revisions unchanged. Selected Monitor definitions are checked without creating Monitor Jobs or provider resources. Draft pull requests do not build. Mark a draft ready for review to start its first build. Fork pull requests receive no Deepline build or check. Copy a registered revision ID from the deployment details to run it before merge:
Replace the example input with the Play’s actual input. This starts a Play run and can use Deepline credits.

​
Deploy and inspect the result

Merge the pull request or push committed changes to the configured production branch. Open Deploys, or inspect the deployment through the CLI:
Deepline validates changed Plays before promoting their live revisions together. Unchanged Plays are skipped by content hash. Monitor provider effects remain separate from this Play promotion. Check the selected commit, workspace, per-Play outcomes, warnings, and Monitor Jobs. Terminal states include succeeded, succeeded_with_warnings, failed, reconcile_failed, cancelled, and superseded. Build compute is metered; deployment details show build duration. An admin can cancel before Plays go live:
Cancellation does not undo Monitor changes already submitted. Inspect their Jobs in the receipt. Cancellation is refused after the Plays are promoted.

​
Roll back from source

Revert the source commit. Push the revert to the production branch. Inspect the new deployment and its live revisions. A revert creates another deployment; it does not reverse earlier provider effects automatically. Review Monitor Jobs separately. Use Repositories to change settings, pause deployments, or unlink a repository. The CLI exposes the same controls. Get the link ID from deepline git list:
Use --enabled to resume. Update the branch, root, manifest, or pull-request checks with deepline git set; its help lists the options. To release repository ownership:
Confirm the link’s new state with deepline git get "$LINKED_REPOSITORY_ID". Pausing or unlinking stops new deployments; live Plays and existing Monitors continue. Decommission schedules, webhooks, callers, and Monitors explicitly.
Use deepline git status to inspect installation state and affected links. After an uninstall, reconnect GitHub and recreate affected links with their original settings. Links from the old installation cannot be resumed. For a suspended installation, restore access in GitHub and inspect each link before resuming deployments.A directory deployment or manual publish can replace a repository-owned live Play. Deepline reports the difference from the linked repository; the next owner push replaces that revision. Choose one deployment owner. Use the Actions guide for the ownership handoff.