Continuous integration (CI)
CI runs your tests and checks automatically on every push, so problems are caught in minutes instead of after they reach main. Sangam-Git's CI is designed to be set up in a few clicks — no hand-written YAML required.
How it works
Your pipeline is defined by a file in your repository: .sangam/ci.yml. Because it lives in the repo, it's versioned with your code — the checks that ran on an old commit are exactly the ones defined at that commit. On every push, Sangam-Git reads this file and runs the steps you defined.
Setting it up — three easy paths
Open a repository and go to the Checks tab, then Set up CI. You have three ways to create your .sangam/ci.yml, and you never have to write YAML from scratch:
1. Pick a starter. Choose a template for your stack (Go, Node, Python, …). Edit it if you like, and Sangam-Git commits .sangam/ci.yml for you.
2. Describe it in plain English. Type what you want — "build a Go service, run tests, then vet" — and Sangam-Git writes the YAML. Review and edit before committing.
3. Import an existing config. Migrating from another host? Sangam-Git can import a GitHub Actions, GitLab CI, or Jenkins pipeline and translate it into .sangam/ci.yml. It shows you import notes to review, because no translation is perfect.
Committing and running
When you commit the file:
- Committing to a branch like
mainstarts a run right away. - Opening a pull request runs CI on the PR first, so you see it pass before merging.
Each run shows its status — Queued, Running, Passed, Failed, Errored, or Canceled — and how long it took. You can open a run to see each job and step, re-run it, or cancel one that's still going.
Making checks required before merge
CI is most useful when it gates merges. Under a repository's Settings → Branch protection, turn on "Require CI checks to pass before merge." Now a pull request into main can't merge until its checks are green — no more "oops, that broke the build" on the main branch.
Scheduled runs
Beyond running on push, you can schedule jobs — for example schedule: daily — to run checks even when nobody pushed. Sangam-Git uses this itself to run a daily vulnerability scan on its dependencies (see Security).
A note on where CI runs
CI jobs currently run on the Sangam-Git server's runner. Stronger isolation between tenants (hardened container sandboxes) is on the roadmap and is a prerequisite before multi-tenant CI is offered widely. If you're self-hosting for a single organization, this is not a concern.
Start simple: a pipeline that just builds and runs your tests on every push already catches most breakage. Add more checks as your project grows.