Auto: [RFC] Simplifique a configuração do rótulo

Gosto da primeira opção. é super simples e limpo, estou tendo problemas para distinguir a diferença entre none e skip . Se eu entendi corretamente, skip não tem relação com o changelog e precisa estar com um rótulo semver, e none irá pular uma versão, mas criar uma entrada única no changelog.

esse método elimina a maioria das abreviações, mas acho que ainda podemos suportar algumas?

por exemplo, o seguinte substituiria o rótulo padrão major , mas também herdaria a descrição e o changelogTitle

{
  labels: [
    {
      name: 'Breaking change',
      releaseType: 'major'
    }
  ]
}

ou apenas editando o título

{
  labels: [
    {
      releaseType: 'major',
      changelogTitle: 'Super Big Changes'
    }
  ]
}

skip é não fazer um lançamento. none significa que a gravadora não tem efeito sobre o lançamento ... então ela pode lançar ou não, dependendo da presença de outras gravadoras. Ele precisa de um nome melhor.

Portanto, de acordo com sua sugestão, os rótulos têm substitutos padrão com base no que releaseType está presente? Eu acho que faz sentido.

Portanto, de acordo com sua sugestão, os rótulos têm fallbacks padrão com base em qual releaseType está presente? Eu acho que faz sentido.

sim

@zephraph Ele precisa de um nome melhor.

Eu acho que é ótimo. Não há nada melhor do que dizer "não é nenhum porque não tem impacto no processo de lançamento, por exemplo, chore / dependências / qualquer coisa".

acho que faz sentido.

Sim, totalmente.

A proposta é incrível.
Eu acho que name e chagelogTitle devem ambos ter padrões baseados em releaseType .

Eu tenho um PR para isso agora. Não aborda o seguinte

1. Os títulos do log de alterações podem ser adicionados aos rótulos, mas não está exatamente claro em que ordem eles têm precedência. Se houver rótulos secundários e de documentação, qual título do changelog tem precedência?

2. Logic maior parte da validação descrita aqui provavelmente deve residir no autobot. Eu não acho que a própria auto deveria forçar isso

3. (relacionado a 1)> Múltiplos rótulos nenhum podem ser incluídos para adicionar o PR em diferentes seções do changelog

Eu não entendo. Como _ "Um rótulo de ignorar só é válido quando emparelhado com um rótulo semver e, caso contrário, é um autônomo." _ Faz sentido? Se eu tenho deps rótulo ou infra , o tipo é skip e quero pular o lançamento por que preciso adicionar o rótulo Semver também? Acho que devo usar none então, mas isso também permite adicionar o rótulo semver, então ... WAT ?! : D

Atualmente eu tenho

    "skipReleaseLabels": [
      "documentation",
      "skip-release",
      "devDeps",
      "infra"
    ],
    "labels": {
      "deps": {
        "name": "deps",
        "title": "🔩 Dependency Updates"
      },
      "devDeps": {
        "name": "devDeps",
        "title": "🔩 Dependency Updates"
      },
      "documentation": {
        "name": "documentation",
        "title": "🗒️ Documentation"
      },
      "core": {
        "name": "core",
        "title": "📦 Core"
      }
    },

e eu quero pular docs, skip-release, devDeps e infra, mas não quero pular deps por exemplo. Porque estou usando renovate e desejo lançamentos de patch em fix(deps) .

Eu também tenho onlyPublishWithReleaseLabel habilitado de qualquer maneira, então não será um grande problema para mim.

E mais uma coisa, changelogTitle na tag next dist? Só estou pedindo esclarecimentos, pois não consta no PR.

@tunnckoCore Acho que sua configuração ficaria assim na nova maneira:

{
  "labels": [
    {
      "name": "deps",
      "title": "🔩 Dependency Updates",
      // when deps are merged create a patch release
      "releaseType": "patch"
    },
    {
      "name": "devDeps",
      "title": "🔩 Dependency Updates",
      "releaseType": "none"
    },
    {
      "name": "documentation",
      "title": "🗒️ Documentation",
      "releaseType": "none"
    },
    {
      "name": "core",
      "title": "📦 Core",
      "releaseType": "patch"
    }
  ]
}

Nenhum atua efetivamente como skip . Mas se você realmente precisasse lançar uma atualização devDep você poderia adicionar patch e uma liberação seria feita. Isso é diferente de adicionar um rótulo skip , que ignoraria o lançamento independentemente de outros rótulos.

changelogTitle

Eu também não fiz isso. Ainda é apenas um título. Vou adicionar isso ao meu PR para o refatorador (ainda não está no próximo. Vou retirá-lo após changelogTitle)

Direito. Certo, ótimo :)

O problema foi lançado em v8.0.0-next.8

É agora? Suponho que prerelease s foram publicados em next ? : pensando: De qualquer forma, não estou com pressa. Ainda lutando com Yarn v2 + pnp e construção / agrupamento.

editar: E a falta de title/changelogTitle ainda implica que não fará uma seção nas notas de lançamento?

@tunnckoCore existem padrões nos títulos do changelog com base na versão que você está lançando.

Estou perguntando sobre os outros "rótulos personalizados" que adicionamos da configuração e que não são sobre o semver. Se eu tiver infra rótulo sem título, ele não será adicionado, certo? E quando eu tiver um título (como em devDeps), ele será adicionado.

: rocket: O problema foi lançado na v8.0.0: rocket:

@adierkens , parece que esse problema foi o principal ímpeto por trás da revisão principal da v8, então estou fazendo esta pergunta aqui ... Há algo especial que preciso fazer para atualizar para a v8 da v7.x?

Se você tiver qualquer labels ou skipReleaseLabels extra, você precisará usar o novo formato

https://intuit.github.io/auto/pages/autorc.html#label -customization

Wooohooo! : tada: Vou tentar no fim de semana.

Em primeiro lugar, mudanças legais para v8!

A respeito de

Os títulos do log de alterações podem ser adicionados aos rótulos, mas não está exatamente claro em que ordem eles têm precedência. Se houver rótulos secundários e de documentação, qual título do changelog tem precedência?

Com base em testes locais, parece que o comportamento atual é:

• atribua um determinado PR ao primeiro rótulo com verdadeiro changelogTitle na ordem de prioridade de releaseType ( major , minor , patch , então todos os outros)
• se o PR tem vários rótulos associados à mesma prioridade releaseType acima, então o PR é incluído na seção do rótulo definido na configuração primeiro (rótulos padrão precedem todos os outros)

Abaixo estão alguns exemplos:

(1): rótulos secundários e nenhum
config:

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "none" },
  { "name": "minor", "changelogTitle": "Enhancement", "releaseType": "minor" }
]

rótulos em PR:

minor

seção de rótulo do changelog: minor

• porque minor releaseType tem maior precedência

(2): rótulos de patch múltiplos
config:

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "patch" },
  { "name": "core", "changelogTitle": "Core Change", "releaseType": "patch" }
]

rótulos em PR:

core

seção de etiqueta do changelog: typescript

• porque o rótulo typescript aparece na configuração antes de core

(3): nenhum rótulo e nenhum rótulo padrão
config:

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "none" }
]

rótulos em PR:

internal

seção de etiqueta do changelog: internal

• porque internal rótulo aparece na configuração antes de typescript (ele aparece na configuração padrão que tem maior precedência entre o mesmo releaseType

@hipstersmoothie , o comportamento / ordem de precedência acima é intencional?

Em caso afirmativo, seria bom adicionar à documentação para que fique claro como as seções de rótulo do changelog são geradas e como as seções têm precedência (eu poderia ajudar com isso, se necessário)

Se não, podemos trabalhar para definir uma ordem de precedência, seja como parte deste problema ou de outro?

Não vejo isso como algo especial ou errado. Parece bastante intuitivo. A única coisa importante é major , minor e patch estar sempre em primeiro lugar no changelog, apenas porque é uma coisa padrão. Mas mesmo que o pedido seja configurável, também está tudo bem.