Propriedades por ambiente

config/producao.yaml

deploy.region: us-central1
deploy.trafficPercent: 50
deploy.platforms: [linux/amd64, linux/arm64]
deploy.canary: false

oren.yaml

pipelines:
  deploy:
    propertyFiles:
      producao: ./config/producao.yaml
      staging: ./config/staging.yaml
    steps:
      - id: publicar
        task: techlite/gcp-cloud-deploy@^1.0.0
        implementation: techlite/gcp-cloud-deploy-gcloud
        inputs:
          region: ${properties.deploy.region}

oren run deploy -p producao

O -p aceita um alias declarado em propertyFiles ou um caminho direto.

O apelido pode dizer de que branch ele é

Só para o oren generate, e só quando você quiser que o CI escolha o ambiente sozinho:

propertyFiles:
  producao:
    file: ./config/producao.yaml
    branches: [main]
  staging:
    file: ./config/staging.yaml
    branches: [develop, 'feature/*']

A forma curta continua valendo, e as duas convivem no mesmo pipeline.

branches não muda nada no oren run — lá o apelido continua sendo escolha explícita de quem executa. Ele não olha o git para adivinhar a branch, ou o mesmo comando passaria a significar coisas diferentes conforme onde é digitado.

O mapa mora aqui, e não dentro do arquivo de propriedades, porque aquele arquivo não tem schema: é livre, e você põe nele as chaves que quiser. Um campo reservado branch: lá dentro acabaria com isso.

Ver Rodando no CI para o que cada plataforma gera a partir disso.

Uma property pode apontar para a saída de um step

O valor de uma property pode ser ele mesmo uma expressão:

config/main.yaml

versao: ${outputs['versao'].version}

# config/develop.yaml
versao: ${outputs['versao'].candidateTag}

inputs:
  image: registry/app:${properties.versao}

É a única coisa que nenhum valor comum consegue fazer: escolher um campo diferente da mesma saída. ${outputs['versao'].${properties.campo}} não é expressável, e nem deveria ser — então a escolha muda de lugar e vai para o arquivo de property, onde é uma linha por ambiente.

É o que permite um pipeline só servir a duas branches: main publica 0.1.4, develop publica 0.1.4-rc.b43c8f5.20260809035558, e nada no oren.yaml muda.

O escopo dela passa a ser a posição, não o ambiente

Uma property que referencia uma saída só vale nos steps depois daquele que a produz. O arquivo parece descrever um ambiente; na prática aquela linha descreve um ponto do pipeline. Usá-la num step anterior falha com “sem saída ainda”.

Dentro de um arquivo de properties só outputs e env são resolvidos. Uma property não pode referenciar outra — o que elimina o problema de ciclo na origem, e impede que o arquivo vire o lugar onde a lógica se esconde.

Segredo atravessa. Uma property que interpola saída secreta sai marcada como secreta, e é redigida do mesmo jeito. Sem isso, bastaria passar a credencial por uma property para ela reaparecer em log.

Um step pode ser condicional

enabled aceita boolean ou expressão:

- id: tag
  enabled: ${properties.commita}
  task: techlite/commit-and-tag@^2.0.0
  implementation: techlite/commit-and-tag-alpine

Só properties e env — nunca outputs. Quais steps rodam precisa ser sabido antes de a execução começar; é o que permite ao oren validate e ao gerador de CI dizerem qualquer coisa sobre o pipeline.

Precisa resolver para um boolean de verdade. A string "false" é recusada em vez de coagida: aceitá-la rodaria o step exatamente ao contrário do escrito.

Ele não some do oren validate

Um step que sumisse conforme um valor seria justamente o defeito que este projeto existe para evitar. Então ele é sempre listado:

[8/8] Comita e cria a tag · tag · commit-and-tag
      condicional · enabled = ${properties.commita}

Com --properties, a mesma linha fica concreta — → roda ou → pulado. O flag é opcional: sem ele todo step continua sendo validado, e só a decisão fica em aberto.

Ele continua sendo travado

O oren install não precisa de --properties, e trava o step condicional mesmo assim.

A regra é que o lock exclui apenas o que o arquivo prova que nunca roda. Um enabled: false literal prova, e fica de fora do lock — é o que permite estacionar um step cujo worker ainda não foi publicado. Uma expressão não prova nada na hora do install, então é travada, e a decisão fica para a execução.

É isso que mantém o oren.lock independente de qual arquivo de properties foi usado.

O oren generate é a exceção

Um CI gerado tem um conjunto fixo de jobs, e ${properties.commita} não existe dentro do GitLab nem do Cloud Build para ser avaliado lá. Então a decisão precisa ser tomada na geração:

oren generate gitlab entrega -p main      # 8 jobs
oren generate gitlab entrega -p develop   # 7 jobs

Sem o flag, gerar um pipeline que tenha step condicional é recusado, nomeando o step. Decidir por conta geraria em silêncio um CI diferente do que se pediu.

Por que YAML e não .properties

Chave pontilhada dá a simplicidade visual de um .properties, mas o formato é YAML por causa dos tipos: os contratos declaram integer, boolean e array, e um formato onde tudo é string obrigaria converter pelo tipo do destino — fazendo o mesmo arquivo se comportar diferente conforme quem o consome.

Aqui 50 é número, false é booleano e a lista é lista.

Aninhamento explícito também funciona, e as duas formas convivem no mesmo arquivo. O que não é permitido é a mesma chave ser valor e agrupamento ao mesmo tempo — um dos dois seria perdido em silêncio.