Getting Started

Design your first pipeline

A new project has no pipeline yet — the path a delivery travels before it lands. This page walks through designing one: a couple of stages, each pointed at a branch, each with a gate that decides when the work moves on.

For what these words mean, see The pipeline: stages and gates. This page is the hands-on setup.

Open the Pipeline page

From your project, open Deliver, then select Pipeline. A project with no stages yet shows an empty state:

  • Heading: “No pipeline stages”
  • Subtext: “Add stages manually or choose a template to get started.”
  • Two buttons: Use Template and Add Stage

You have two ways forward. Start from a template if you want a sensible default in one click, or add stages by hand if you want to build the path yourself. Most first pipelines start from a template.

Start from a template

Select Use Template (or Templates in the top bar). The Choose a Pipeline Template dialog lists four options:

  • Simple — two stages, Development (dev) and Production (main). A good default.
  • Standard — three stages: Development, Staging, Production.
  • Enterprise — four stages: Development, QA, UAT, Production.
  • Custom — an empty pipeline you fill in yourself.

For a first pipeline, pick Simple. The dialog closes and the two stages appear as a row, laid out left to right with arrows between them.

A template is only a starting point. Once it’s loaded you can rename stages, change their branches, add or remove them, and set their gates — exactly as if you’d built them by hand.

Configure a stage

Select a stage card in the row. Its settings open in the Stage Configuration panel beside the pipeline.

For your first pipeline you only need three fields:

  • Stage name (required) — what you call this step, for example Development or Production. Up to 100 characters. Each stage’s name must be unique within the pipeline.
  • Branch (required) — the branch in your repository this stage targets, typed in free-form. The placeholder shows the idea: e.g. main, dev, staging. When a run reaches the stage, DIJJI.ai opens a pull request against this branch.
  • Auto-merge PR — this is the stage’s gate: it decides whether the run pauses for you. Every stage opens a pull request that must be merged before the run advances; Auto-merge PR controls who merges it. Left off (the default), the run waits for you to merge — the human checkpoint. Turned on, DIJJI.ai merges it and the run flows straight through. Leave it off on any stage you want to review before it goes further.

A typical Simple pipeline leaves Auto-merge PR off on Development — so you review and merge before anything goes further. On Production, leave it off to make the final merge yourself, or turn it on to let DIJJI.ai merge and finish hands-off.

The panel holds several more settings — Wait for deploy confirmation, Free the project while this stage waits, End-of-stage behavior, an E2E trigger, and an E2E Targets list. Building a first pipeline from a template, you can leave them as they are. One to know about: if you later add a stage by hand, Wait for deploy confirmation starts switched on, which makes a run pause after that stage’s pull request is merged until a deployment is confirmed — see Deploy confirmation and the deploy wait if a run stops there.

When the stage runs end-to-end tests, those tests need somewhere to point. E2E Targets is a repeatable list: select + Add target to add one, then fill in a Title (for example Web App, Backoffice, or API), a check type — Browser or API — a URL, and, if the target needs a sign-in, an optional throwaway Test Username and Test Password. Add as many targets as the stage deploys. Use only dev or disposable test accounts; the login fields are optional, so leave them blank to skip sign-in for that target.

Quality and speed settings are no longer here. They live on project Settings, in the Engine Configuration card — a project-wide choice of a quality/speed tier plus a reasoning-depth setting, where the deeper option reasons more on harder tasks at a higher cost. You can leave the defaults to start. See Engine Configuration for what each option does.

Add, reorder, or remove stages

If you built from Custom, or want to change a template:

  • Add a stage — select Add Stage. A pipeline can hold up to 20 stages; past that, the button is disabled.
  • Reorder stages — drag a stage card by its handle and drop it into the new position. Stages run in the order shown, left to right.
  • Remove a stage — select the stage, then Remove in the Stage Configuration panel. You can’t remove the last remaining stage; a pipeline needs at least one.

Set the trunk branch

The Trunk Branch field, at the top of the page, is the long-lived branch feature branches are created from. It’s already filled from your project settings — usually main. Leave it as-is unless your repository uses a different trunk.

Save the pipeline

While you have unsaved edits, the page shows “Unsaved changes. Click Save to apply.”

Select Save. A Save Pipeline dialog confirms how many stages you’re saving and warns that removed stages will be deleted. Select Save Pipeline to confirm.

If anything is incomplete — a missing name, a missing branch, duplicate stage names — DIJJI.ai marks the problem instead of saving. Fix it and save again.

When the save succeeds, the page shows “Pipeline saved.” Your project now has a path for its work to travel.

What’s next

With a pipeline in place, your project is ready to do work. The next step is to bring in a task and run it — see Run your first task or Execute a task. Projects, tasks, and runs explains how a run moves through the pipeline you just built.