Primeiro pipeline

O caminho de quem vai usar tasks — que é o caso mais comum. Se você vai escrever uma task nova, veja Criar tasks.

mkdir meu-projeto && cd meu-projeto
oren init

✓ projeto criado
      oren.yaml
      .gitignore
      .oren/registry/

Só isso: um pipeline vazio e um lugar para as tasks morarem. Nenhum código, nenhum Dockerfile — o trabalho vem de fora.

Trazer uma task

oren add ../workers/analyze-commits

✓ techlite/analyze-commits adicionada
      .oren/registry/analyze-commits.task.yaml
      .oren/registry/analyze-commits-shell.impl.yaml
      .oren/registry/analyze-commits-node.impl.yaml

O contrato exige do seu ambiente:
      low                source git-repository

Repare que ele mostra o que a task vai pedir antes de você usá-la, e traz todas as implementações disponíveis — escolher por você seria decidir privilégio no seu lugar.

Enquanto o portal não existe

A origem é um diretório no disco. Clone o repositório de workers e aponte para a task que quiser. Com o portal, a origem passa a ser uma referência publicada e o resto do fluxo não muda.

Escrever o step

oren.yaml

apiVersion: oren.sh/v1
kind: Pipeline
pipelines:
  dev:
    steps:
      - id: analise
        task: techlite/analyze-commits@^1.0.0
        implementation: techlite/analyze-commits-alpine
        inputs:
          defaultChange: minor
        dependencies:
          source: "."

O oren add escreve esse step para você, preservando os comentários do arquivo. As dependências saem vazias — os caminhos são seus.

Executar

oren run dev

[1/1] analise · analyze-commits
      │ analisando commits desde v1.0.0
      │ 1 commits analisados
      │ classificação: patch
      ✓ 3.7s

Entendendo a saída

│ analisando commits... — o que o worker imprimiu. stdout e stderr são log livre; não carregam dados: o que o step produz é o JSON de saída, validado contra o contrato. Saída fora do formato declarado falha o step mesmo com código de saída zero.

Vendo entrada e saída

Elas não aparecem por padrão — num pipeline real enchem a linha com JSON que ninguém lê. Use -v:

oren run dev -v

      entrada {"defaultChange":"minor","tagPattern":"v[0-9]*.[0-9]*.[0-9]*"}
      saída {"change":"patch","major":false,"minor":false,"patch":true,...}

O tagPattern aparece sem estar no pipeline: veio do default declarado no contrato.

Nada se perde sem a flag. Os dois ficam em .oren/runs/<id>/steps/<step>/, e a entrada do step que falhar é impressa junto do erro — que é quando ela deixa de ser ruído e vira a primeira coisa que se olha.

Travar as versões

oren install

Grava o oren.lock com o digest exato de cada imagem. Commite — é o que garante que todos executem o mesmo código. Ver Reprodutibilidade.

Verificar sem executar

oren validate

Resolve contratos e implementações, confere dependências e valida os inputs literais — sem subir container nenhum. Roda em cerca de um segundo, e é o que você quer num hook de commit.