CI/CD Pipelines

Automated build, test, and deploy workflows triggered by Git events.

What Are Pipelines?

Pipelines are automated workflows that run when code changes occur in your repository. They handle the repetitive, error-prone tasks that every software project needs — building the code, running tests, checking for lint violations, deploying to staging, and releasing to production. By automating these steps, pipelines ensure consistency and catch problems before they reach users.

Bosca Git pipelines are tightly integrated with the rest of the Git system. Pipeline results are reported as commit status checks that feed into branch protection rules. If a required pipeline fails, pull requests cannot be merged until the failure is resolved.

Pipeline Triggers

Pipelines run in response to events. You configure which events trigger each pipeline, so different workflows can respond to different situations:

Trigger	When It Fires	Typical Use
Push	Code is pushed to a branch.	Run tests and builds on every push. Often filtered to specific branches like main or develop.
Pull Request	A pull request is opened, updated with new commits, or reopened.	Validate proposed changes before they are merged. Results appear as status checks on the PR.
Tag	A tag is created in the repository.	Build release artifacts, publish packages, or trigger deployment workflows when a version is tagged.
Manual	A user manually starts the pipeline from the UI.	On-demand tasks like deploying to a specific environment, running a full regression suite, or generating reports.
Schedule	A cron-based schedule triggers the pipeline at defined intervals.	Nightly builds, periodic security scans, dependency update checks, or scheduled deployments.

Branch and Path Filtering

Triggers can be refined with branch and path filters. Branch filters let you run a pipeline only when changes are pushed to specific branches — for example, only triggering a deployment pipeline on pushes to main. Path filters let you restrict a pipeline to changes in specific directories, which is essential for monorepo workflows where a single repository contains multiple projects and you only want to build the project that actually changed.

In a monorepo, combine branch and path filters to create targeted pipelines. A pipeline that only runs when files under a specific project directory change avoids wasting time rebuilding projects that were not affected by a commit.

Pipeline Components

A pipeline is composed of jobs, and each job is composed of steps. This two-level structure gives you control over what runs, in what order, and on what infrastructure.

Jobs

A job is a unit of work that runs on a single agent. Jobs within a pipeline can run in parallel or be ordered through dependencies — a deploy job might depend on a build job, ensuring the build completes successfully before deployment begins.

Each job specifies which agent it should run on, what steps to execute, and optionally which other jobs it depends on. If a job's dependencies fail, the job is skipped rather than running against a broken foundation.

Steps

Steps are the individual commands or actions within a job. They run sequentially — each step starts after the previous one finishes. If a step fails (returns a non-zero exit code), subsequent steps in the job are skipped by default and the job is marked as failed.

Each step produces logs that are streamed in real time, so you can monitor progress and diagnose failures as they happen rather than waiting for the entire pipeline to finish.

Matrix Expansion

Matrix expansion lets you run the same job with different parameters without duplicating the job definition. You define a set of variables (for example, operating systems or language versions), and the platform creates a separate job instance for each combination. This is commonly used to test across multiple environments — running the same test suite on different Node.js versions, or building for multiple target platforms from a single job definition.

Matrix jobs run in parallel by default. If you have a matrix of three OS versions and four language versions, that creates twelve parallel job instances, each testing a different combination.

Concurrency Control

When changes are pushed rapidly — for example, several commits in quick succession — multiple pipeline runs can queue up for the same branch. Concurrency controls let you manage this:

Concurrency groups. Pipelines can be assigned to a concurrency group (typically based on the branch name). Only one pipeline in a given concurrency group runs at a time. Additional runs are queued until the current one finishes.
Cancel in-progress runs. When a new pipeline is triggered and an older run in the same concurrency group is still executing, you can optionally cancel the in-progress run. This is useful for PR pipelines where only the latest push matters — there is no point finishing a validation run for code that has already been superseded.

Pipeline Lifecycle

Every pipeline run moves through a defined set of states:

State	Meaning
Queued	The pipeline has been triggered and is waiting for an available agent. If concurrency limits apply, it may also be waiting for another run in the same group to finish.
Running	The pipeline is actively executing on an agent. Jobs and steps are being processed.
Success	All jobs completed without failures. Status checks are reported as passing.
Failure	One or more jobs failed. Status checks are reported as failing, which may block PR merges if the check is required by branch protection.
Cancelled	The pipeline was cancelled — either manually by a user or automatically by concurrency control when a newer run superseded it.

Agents

Agents are the machines that execute pipeline jobs. Bosca Git supports two types of agents:

Persistent agents. Long-running machines that stay connected and pick up jobs as they arrive. These are suitable for environments where you have dedicated build servers or VMs that you manage yourself.
Ephemeral agents. Short-lived instances that are provisioned on demand for a single job and destroyed afterward. These provide clean, reproducible environments for every run and are well-suited to cloud-based or containerized infrastructure.

Job Routing with Labels

Agents are assigned labels that describe their capabilities — for example, what operating system they run, what tools are installed, or what network access they have. Jobs specify which labels they require, and the platform routes each job to an agent that matches. This lets you direct specific jobs to specific infrastructure: build jobs might need agents with high CPU, while deployment jobs might need agents with access to production networks.

Commit Status Checks

When a pipeline runs against a branch or pull request, the results are reported back as commit status checks. These status checks integrate with branch protection — if you configure a branch to require specific status checks, pull requests cannot be merged until those checks pass.

Status checks appear on the pull request page, giving reviewers immediate visibility into whether the automated validations have passed. A green check means the pipeline succeeded; a red X means something failed and needs attention.

Name your pipeline status checks descriptively — names like "build," "unit-tests," and "lint" make it immediately clear what passed or failed. When a required check fails, the name is the first thing someone sees when trying to understand what went wrong.

Step-Level Log Streaming

Pipeline logs are streamed in real time as each step executes. You do not need to wait for the entire pipeline to finish before investigating a problem. If a step is failing, you can watch the output live and see exactly where things go wrong. Logs are retained after the pipeline completes, so you can review them later for debugging or auditing.

Platform Integration

Beyond standard CI/CD functionality, Bosca Git pipelines can interact with the broader Bosca platform:

Trigger platform events. Pipeline completion can fire events that trigger content publishing workflows, cache invalidations, or notification rules elsewhere in the platform.
Work Ops updates. Pipeline results can be linked to Work Ops tasks, giving project managers visibility into build and deployment status directly from their task boards.
Webhook notifications. Pipeline start and completion events can be delivered to external systems via webhooks, enabling integration with Slack, PagerDuty, deployment trackers, and other tools.