What Oren is

Every team rewrites the same ten pipelines. Build, tag, push, deploy — the same work, copied between projects and companies, then translated again into each CI’s YAML.

“Analyse commits and decide the next version” is the same task in every repository in the world. Yet every team rewrites it from scratch, tied to their CI’s primitives, with no way to say what it takes in and what it gives back.

With no contract there is no substitution — swapping the implementation means rewriting the pipeline. There is no comparison either: two solutions to the same problem are not comparable if they do not even describe the same problem.

The model

Oren separates what a task does from how it is done.

Piece	Answers	Who writes it
Task	what goes in, what comes out, which resources it needs	the contract author
Implementation	which image does the work, where each resource is mounted	the worker author
Pipeline	which tasks to run, with which values	you, in oren.yaml

One Task can have several Implementations. The pipeline references the task, not the image — that is what lets you swap implementation without rewriting anything.

# the contract: published once, implemented by anyone
spec:
  inputs:
    type: object
    properties:
      defaultChange: { type: string, enum: [major, minor, patch, none] }
  outputs:
    type: object
    required: [change]
    properties:
      change: { type: string }
  dependencies:
    source:
      type: git-repository

# the pipeline, in your repository
steps:
  - id: analyze
    task: techlite/analyze-commits@^1.0.0
    implementation: techlite/analyze-commits-alpine
    inputs:
      defaultChange: minor
    dependencies:
      source: "."

What this unlocks

Interchangeable implementations. The same contract can have one implementation in shell and another in Node, producing identical output. You swap by changing one line.

Visible cost. Every resource a task requires from your environment is declared and typed, with a privilege level. An implementation that requires the Docker socket shows up as more expensive than one using kaniko — and the choice becomes an informed one.

Platform independence. The pipeline is a single file. Running it locally and generating your CI’s native configuration are separate decisions.

Two paths

The documentation follows two tracks, and it is worth knowing which one you are on:

If you want to	Start at
run pipelines with tasks that already exist	First pipeline and Using tasks
write a new task, for yourself or to publish	Creating tasks

Whoever only uses tasks never needs to know what the v1 protocol is, or how a worker is packaged.

What Oren is not

It is not a CI. It does not schedule, does not listen for webhooks, has no execution dashboard. It defines what a task is and runs it — in your terminal or inside the CI you already use.