Write a task once.
Run it anywhere.

The problem

Reusing a pipeline today means copy and paste

"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. And there is no reuse between organisations, because there is nothing to reuse beyond a YAML file.

Portability

The pipeline does not belong to your CI

A pipeline written in GitLab CI only runs on GitLab. Reproducing it on your machine means guessing what the runner does, and moving platform means rewriting everything. In Oren the pipeline is a single file, and where it runs is a separate decision.

# on your machine, the same thing that runs in production
oren run dev

# or generate your platform's native configuration
oren generate gitlab     > .gitlab-ci.yml
oren generate github     > .github/workflows/ci.yml
oren generate cloudbuild > cloudbuild.yaml

Both paths run exactly the same containers, with the same contracts.

This works because dependencies are typed. The generator knows that a secret/gcp-service-account becomes a protected variable on GitLab, a secret on GitHub Actions or a Secret Manager reference on Cloud Build. A bare file path would tell nobody any of that.

The idea

A task is a contract. A worker is one way of fulfilling it.

The contract declares what goes in, what comes out and which resources of the environment the task needs — and nothing about how the work gets done. That is each implementation's choice, and it is why they can be swapped without the pipeline changing a line.

# the contract — published once
apiVersion: oren.sh/v1
kind: Task
metadata:
  name: analyze-commits
  namespace: oren
  version: 1.0.0
spec:
  inputs:
    properties:
      defaultChange:
        type: string
        enum: [major, minor, patch, none]
  outputs:
    properties:
      change: { type: string }
      minor:  { type: boolean }
  dependencies:
    source:
      type: git-repository

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

  - id: build
    task: techlite/build-docker-image@^1.0.0
    inputs:
      imageName: acme/api
      incrementMinor: ${outputs['analyze'].minor}
    dependencies:
      source: "."

Execution

A worker is an image that reads one file and writes another

There is no mandatory SDK, no preferred language and no API to implement. The CLI mounts the dependencies, writes the inputs to disk and reads the output. That is the whole protocol:

# a complete worker, in shell
. /oren/oren.sh

IMAGE=$(oren_input .imageName)
docker build -t "$IMAGE" /source
oren_output image "$IMAGE"

The first line loads the SDK, a shell file copied into the image — nothing is injected. stdout and stderr stay free for logging: they carry no data.

Dependencies

What a task asks of your environment is explicit

Folders, credentials and access to Docker are not configuration details — they are the cost of running that worker on your machine. Every dependency is declared and typed, and the CLI grants exactly what was declared. Nothing more.

This makes two implementations of the same contract genuinely comparable. If both build the same image and one requires the Docker socket while the other uses kaniko, the difference stops being invisible — and the choice becomes an informed one.

Portal

An open catalogue between organisations

Contracts published by one organisation can be implemented by any other. That is what stops the original problem from coming back at another scale: if every company had to write its own contract, we would be back to ten versions of the same thing.

• Discover

  Find the task that does what you need and compare the available implementations side by side.

• Add

  oren add techlite/build-docker-image writes the step, resolves the implementation and points at what is left to configure.

• Or implement

  oren init worker scaffolds a whole task — contract, worker, implementation and an example pipeline — in shell or Node.

Published versions are immutable and never disappear; they are only deprecated. Private implementations remain possible for whoever has an internal process to protect, while the contract stays public — and with it, comparability.

Get started

Three commands

# the CLI
npm install -g @oren-sh/cli

# a project, and a task from the catalogue
oren init
oren add techlite/analyze-commits

# runs on your machine, from the same file that runs in CI
oren run dev

To publish your own, oren login and oren publish. The example workers live under techlite/*. Whoever publishes a contract does not choose who implements it — any organisation can, and that is what gives consumers an alternative.

Who uses it

In production today

Techlite. Maintains and publishes the reference workers under techlite/* — analysing commits, building and pushing images, Terraform, Cloud Deploy — and runs delivery pipelines built from them: version derived from conventional commits, two images published to Artifact Registry, and a release created through Cloud Deploy, from the same file that runs on a laptop.

This is version 0.5.2. Published versions are already immutable, but the document format may still change before 1.0.