Bosca / Git

CI/CD

Build and ship, on your machines

A pipeline is YAML checked into the repo. The server discovers it, schedules its jobs, and dispatches them to CI agents you run — then the results report back to the branch as commit statuses.

The pipeline

YAML in, a run out

Jobs declare which agent they need, what they depend on, and an ordered list of steps. Matrixed jobs fan out across values, each step records its status, exit code, and timing, and a run moves from queued to running to a final outcome you can watch live.

  • Jobs depend on other jobs, so a run is a graph, not just a list.
  • Steps publish artifacts — named, sized, and retained by policy — for later jobs or other repos.
  • Pipeline secrets are set per repo, name-only and write-only, and injected at run time.
  • Run on repository activity, on demand, or from a five-field cron schedule kept in the same YAML.
run #512 · main
buildlinux · x64success
test ×3linuxsuccess
deployprod-readonlyrunning
reports ci/build, ci/test

Your own agents

Runners you control

Jobs run on agents you register — nothing executes on hardware you don't own. An agent registers once with a one-time token, then pulls work it's eligible for. Free-text labels route each job to the right machine.

  • A runner executes jobs directly; an orchestrator boots ephemeral runners on demand — cloud VMs that report back and tear down.
  • Runner profiles can also dispatch durable Kubernetes jobs with an ephemeral agent for each CI job.
  • Labels like linux, gpu, or prod-readonly match a job's requirement to an online agent.
  • Agents show online, busy, draining, or offline — with the exact step a busy one is running.
agents
runner-01linux · x64 · dockerbusy
runner-02linux · gpuonline
orchestratorboots ephemeral VMsonline
vm-9f3c ephemerallargebusy

Cross-repo builds

Wait for what another build makes

A job can declare that it needs an artifact from the registry before it dispatches — even one produced by a different repository. The coordinates resolve when the run is created, a version prefix like 6.0.* matches any patch, and the job waits, then dispatches once the last requirement is published.

  • Multi-repo release trains coordinate through artifacts instead of brittle timing.
  • If a requirement never arrives, the job times out and names exactly what was missing.
job · package
requires:
  - artifact: core-server
    version: 6.0.*
  - artifact: web-bundle
    version: 6.0.*
# waits, then dispatches on publish

Operate and release

Recover the run. Control the release.

CI operations stay at the level where the problem happened. Restart a failed job without replaying successful work, stop work that should no longer run, and move artifacts through release and promotion gates with the evidence attached.

Targeted recovery

Re-run one job or only the failed jobs, cancel a queued or active job, and delete terminal runs when their record is no longer needed.

Scheduled CI

Put a cron schedule beside the jobs in repository YAML and let Bosca create the run at the appointed time.

Release and promotion

Publish native release artifacts, promote an existing build, and keep approval and verification gates in the pipeline that ships it.

Keep exploring

More on Git