# Deploy a partir de git tag (`source: type: tag`)

A partir da v2.57.0, uma instância pode deployar o código de uma git tag em vez de uma branch ou da dist. A tag é resolvida relativa a uma branch — só contam tags alcançáveis por ela (o "branch.tag") — e a versão do deploy vira o nome da tag.

# Quando usar

• Deployar exatamente uma versão marcada (v1.2.2) em produção.
• Sempre subir a maior release que casa um padrão (v*).
• Separar canais por sufixo de tag (v*.rc, *.prod).

# Sintaxe

instances:
  production:
    domain: app.projeto.com.br
    source:
      type: tag
      branch: main        # OBRIGATÓRIO — só tags alcançáveis por esta branch
      tag: "v*"           # 3 modos, ver abaixo
      sort: semver        # opcional: semver (default) | date
    keep_versions: 3

# Os três modos

O valor de tag decide o comportamento pelo formato:

O matching é glob (* = qualquer sequência, ? = um caractere), não regex. O git proíbe */? em nome de tag, então um valor com esses caracteres só pode ser glob — a detecção é inequívoca.

# Ordenação (`sort`)

• semver (default): git tag --sort=-v:refname — a maior versão. Bom para v*, v1.2.*.
• date: git tag --sort=-creatordate — a mais recente por data de criação.

Use date para padrões com sufixo custom (v*.rc, *.prod). O version-sort do git não ordena bem esses sufixos — por exemplo, rankeia v1.10.0.rc acima de v1.10.0. O modo vazio ignora sort e usa sempre date.

# Exemplos

Maior release estável na main:

source:
  type: tag
  branch: main
  tag: "v*"
  sort: semver

Pin numa versão exata:

source:
  type: tag
  branch: main
  tag: "v1.4.2"

Canal de RC (o RC mais recente por data):

source:
  type: tag
  branch: main
  tag: "v*.rc"
  sort: date

# Como funciona

1. O runner clona o repo completo (todas as branches + tags) no pull/ — a reachability (--merged) e o sort de tags precisam do histórico e das tags.
2. Resolve a tag conforme o modo/sort, relativa a origin/<branch>.
3. Faz checkout do commit da tag.
4. A versão do deploy = o nome da tag resolvida (ex: v1.4.2), independente de version.source.

# Deployar

runner deploy meu-app

A instância type: tag resolve e deploya a tag. No log:

[tag] 'v*' → v1.4.2 @ a1b2c3d
  Versão:  v1.4.2

# Auto-deploy no cron (canal de release)

A partir da v2.58.0, o fetch --deploy (o cron do runner) detecta tags novas e deploya sozinho:

• glob (v*) e vazio ("") funcionam como canal de release automático: quando surge uma tag nova (maior semver / mais recente) num commit novo, o cron sobe sozinho.
• pin (v1.2.2) nunca auto-deploya — resolve sempre o mesmo commit, então fica fixo até você mudar a tag no manifesto.

runner fetch --deploy meu-app    # detecta tag nova e deploya (glob/vazio)

O REPO VER no runner fetch mostra o nome da tag que o próximo deploy vai publicar. Uma tag nova apontando para o mesmo commit de uma já deployada não dispara deploy (nada mudou no código).

# Erros comuns

# Veja também

• Anatomia do .deploy.yml — schema completo do manifesto.
• Dois deploys da mesma branch — quando cada deploy precisa de config diferente.