Understanding Pipeline

A pipeline connects a build with its job dependencies and downstream jobs. This example publishes a file in Build and reads it in Deploy, so you can see which upstream build supplied the artifact.

Create a pipeline

Create a project with a main branch and a working Docker job executor. Save this as .onedev-buildspec.yml:

version: 53
jobs:
- name: Build
  steps:
  - !CommandStep
    name: Build application
    runInContainer: true
    image: alpine:3.20
    interpreter: !PosixInterpreter
      shell: sh
      commands: echo @build_number@ > app.txt
    useTTY: false
    runAs: '0:0'
    condition: SUCCESSFUL
  - !PublishArtifactStep
    name: Publish application
    artifacts: app.txt
    condition: SUCCESSFUL
  retryCondition: never
  maxRetries: 3
  retryDelay: 30
  timeout: 3600
- name: Deploy
  steps:
  - !CommandStep
    name: Verify promoted artifact
    runInContainer: true
    image: alpine:3.20
    interpreter: !PosixInterpreter
      shell: sh
      commands: cat app.txt
    useTTY: false
    runAs: '0:0'
    condition: SUCCESSFUL
  jobDependencies:
  - jobName: Build
    requireSuccessful: true
    artifacts: '**'
  retryCondition: never
  maxRetries: 3
  retryDelay: 30
  timeout: 3600

Run Build, then open its Pipeline tab. Users need code read permission to see this tab. Run Deploy from the pipeline or promote the successful Build to Deploy. Deploy reads app.txt from its Build dependency and prints that build's number.

The Depends on link on the build page shows the exact prerequisite build. See Build Promotion for the promotion menu.

Rerunning jobs

Do not assume that starting a job from the file or commits page always creates a new build number or rebuilds every dependency. Running the same job for the same commit and parameters can rerun an existing build and reuse its prerequisite. Check Depends on and the artifact contents to see what actually ran. A new commit gives this example a new Build/Deploy pair.

Automate deployment

To run Build whenever main changes, add this under the Build job (at the same indentation level as steps):

  triggers:
  - !BranchUpdateTrigger
    branches: main
    userMatch: anyone

To start Deploy after its successful dependency finishes, add this under the Deploy job:

  triggers:
  - !DependencyFinishedTrigger {}

Commit a change and open Builds. Build runs first and publishes app.txt; Deploy then starts automatically. Its Submit Reason says that the dependency job finished, and its log prints the upstream build number.

Alternatively, put the Branch update trigger on Deploy and remove the triggers from Build. Starting Deploy also starts its required Build dependency, then waits for that dependency before executing its own steps. The dependency's Require Successful setting prevents deployment after a failed Build.

The visual editor exposes the same settings under Triggers and Job Dependencies. Branch update triggers ignore commits containing skip markers such as [skip ci].