Adicionando tasks

oren add techlite/analyze-commits

Copia o contrato e todas as implementações dele para .oren/registry/ do seu projeto:

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

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

2 implementações — qual usar?
      1) low                techlite/analyze-commits-alpine
      2) low                techlite/analyze-commits-node

Todas as implementações vêm juntas de propósito, e a escolha é sua: decidir por você seria escolher privilégio no seu lugar. Quando há mais de uma, o comando lista o custo de cada uma e pergunta — em CI, use --impl <nome>.

Ele escreve o step no seu oren.yaml

Depois da escolha, o step é acrescentado ao pipeline:

      - id: analyze-commits
        task: techlite/analyze-commits@^1.0.0
        implementation: techlite/analyze-commits-alpine
        dependencies:
          source: ""

Os comentários e a formatação do seu arquivo são preservados — ele é editado, não reescrito. As dependências saem vazias: um caminho de disco é seu, não do Oren. oren validate aponta o que falta preencher.

Use --no-step se quiser só registrar a task, ou --pipeline <nome> quando houver mais de um pipeline no arquivo.

O que ele te conta antes de você usar

O que a task exige do seu ambiente, com o privilégio de cada dependência. É a informação que você quer antes de escrever o step, não quando o pipeline pedir autorização.

Se a task age sobre o mundo. Tasks com effects: external — publicar, fazer deploy, criar tag remota — recebem um aviso.

Se a implementação constrói de diretório local. Nesse caso ela só funciona enquanto aquele caminho existir na sua máquina, e não pode ir para o CI.

As duas origens

Referência publicada — namespace/nome, com range opcional:

oren add techlite/version-bump
oren add techlite/version-bump@^1.0.0

Diretório no disco — é o caminho de quem escreve workers, cuja implementação ainda tem build apontando para um Dockerfile local. Não precisa de registry configurado:

oren add ../workers/version-bump

Não há prefixo para distinguir: qualquer coisa que o filesystem entenda (começa com ., /, ~) é caminho; o resto é referência.

Configurando o registry

export OREN_REGISTRY=https://seu-portal

Ou {"registry": "..."} em .oren/config.json.

É configuração do ambiente, não do pipeline: a mesma equipe pode apontar para a instância pública, para uma self-hosted ou para nenhuma, sem que o oren.yaml — que é compartilhado — mude. O que impede isso de virar “resolve diferente em cada máquina” é o oren.lock, que congela o resultado.

Por que existe um registry local

O oren.yaml referencia tasks por nome e versão, não por caminho:

task: techlite/analyze-commits@^1.0.0
implementation: techlite/analyze-commits-alpine

É o que torna o pipeline portável — um caminho de disco não sobreviveria a outra máquina nem a um runner de CI. O registry é quem resolve esse nome para o contrato de verdade.

Para uma task publicada, o registry local é cache: o oren install baixa o que falta, então apagar .oren/registry/ e rodar de novo reconstrói — como node_modules.

Para uma task local — a que veio de um diretório, cuja implementação aponta para um Dockerfile da sua máquina — ele é a FONTE. Essa não existe publicada em lugar nenhum, então precisa ser commitada.

Atualizando

oren add sobrescreve o que estiver no registry local. Para atualizar uma task, rode de novo apontando para a versão nova, e depois:

oren install     # trava os novos digests

Se a nova versão pedir mais privilégio, o Oren pergunta de novo na próxima execução — a autorização anterior não é herdada.

Publicando

Quem escreve workers publica com oren publish, depois de autenticar uma vez com oren login. Os dois estão em O portal, junto de organizações, papéis e do que uma versão publicada nunca deixa de ser.

O que o registry recusa

Versão que já existe (409). Publicada é imutável — é o que permite ao oren.lock prometer que o mesmo pipeline executa o mesmo código. Para corrigir, suba metadata.version.

Documento fora do schema (422), com a lista de problemas. O portal valida com o mesmo schema que a sua CLI usa.

Namespace do qual você não é membro (403). Publicar exige papel publicador ou admin na organização — e a checagem usa o metadata.namespace do documento, não um parâmetro.

Implementação com build:. Ela aponta para um Dockerfile da sua máquina; quem consome receberia uma referência que não existe do lado dele. Publique a imagem e troque por image:.