Publicando

Durante o desenvolvimento, a implementação constrói do diretório local:

runtime:
  type: container
  build:
    context: ./worker

Isso não é publicável — quem consome precisa da imagem pronta, não do código-fonte. Um job de CI também não tem o seu diretório, então oren generate recusa implementações assim.

Publicar

docker build -t seuusuario/minha-task-alpine:1.0.0 worker/
docker push seuusuario/minha-task-alpine:1.0.0

runtime:
  type: container
  image: seuusuario/minha-task-alpine:1.0.0

oren install    # resolve a tag para digest

Com a imagem no ar, o contrato vai para o catálogo:

oren publish .

O nome carrega a escolha de engenharia

O repositório deve refletir a implementação, não a task:

oren-ci-build-docker-image-kaniko
oren-ci-push-docker-image-skopeo
oren-ci-analyze-commits-alpine

O sufixo deixa evidente que aquilo é uma forma de satisfazer o contrato. Alguém publica -buildkit e as duas coexistem no catálogo, comparáveis pelo privilégio que exigem. Com o nome da task, pareceria que aquela é a implementação.

Uma imagem pode servir várias tasks

terraform-plan e terraform-apply são contratos diferentes — effects, outputs e dependências distintos — mas usam o mesmo binário. As duas implementações apontam para a mesma imagem e escolhem o script pelo entrypoint:

runtime:
  image: acme/oren-ci-terraform-hashicorp:1.0.0
  entrypoint: ["/worker/plan.sh"]

Subcomando é entrypoint, e quem escolhe é a implementação — não um input do contrato. Unir os dois num contrato com um campo comando forçaria declarar o pior caso em effects, perdendo a informação de que planejar é seguro repetir.

Versão publicada é imutável

Republicar uma versão com outro conteúdo quebra quem depende dela, sem sinal — e transfere silenciosamente a autorização de acesso que alguém concedeu à versão anterior.

Para publicar de novo, suba a versão da implementação.