Auto: [RFC] Simplifique la configuración de etiquetas

Me gusta la primera opción. es súper simple y limpio, tengo problemas para distinguir la diferencia entre none y skip . Si entiendo correctamente, skip no tiene relación con el registro de cambios y debe estar con una etiqueta semver, y none omitirá un lanzamiento pero creará una entrada de registro de cambios única.

este método elimina la mayoría de los métodos abreviados, pero creo que aún podríamos admitir algunos.

por ejemplo, lo siguiente anularía la etiqueta major predeterminada pero también heredaría la descripción y el changelogTitle

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

o simplemente editando el título

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

skip es no hacer un lanzamiento. none significa que la etiqueta no tiene ningún efecto en el lanzamiento ... por lo que puede lanzarse o no, dependiendo de la presencia de otras etiquetas. Necesita un nombre mejor.

Entonces, según su sugerencia, las etiquetas tienen alternativas predeterminadas basadas en lo que releaseType está presente. Creo que eso tiene sentido.

Entonces, según su sugerencia, las etiquetas tienen alternativas predeterminadas basadas en qué tipo de lanzamiento está presente. Creo que eso tiene sentido.

sí

@zephraph Necesita un nombre mejor.

Creo que es genial. No hay nada mejor que decir "no es ninguno porque no tiene ningún impacto en el proceso de lanzamiento, por ejemplo, tareas / dependencias / lo que sea".

creo que tiene sentido.

Sí, totalmente.

La propuesta es impresionante.
Creo que name y chagelogTitle deberían tener valores predeterminados basados ​​en releaseType .

Tengo un PR para esto ahora. No aborda lo siguiente

1. Los títulos de los registros de cambios se pueden agregar a las etiquetas, pero no está exactamente claro en qué orden tienen prioridad. Si existen etiquetas secundarias y de documentación, ¿qué título del registro de cambios tiene prioridad?

2. Logic mayor parte de la validación descrita aquí probablemente debería estar en autobot. No creo que el auto en sí debería estar forzando esto

3. (relacionado con 1)> Se pueden incluir varias etiquetas none para agregar el PR en diferentes secciones del registro de cambios

No lo entiendo. ¿Por qué _ "Una etiqueta de omisión solo es válida cuando se combina con una etiqueta semver y, de lo contrario, no es una operación" _ tiene sentido? Si tengo deps etiqueta o infra , el tipo es skip y quiero omitir la publicación, ¿por qué necesito agregar la etiqueta semver también? Supongo que debería usar none entonces, pero esto también permite agregar la etiqueta semver, así que ... ¡¿WAT ?! :D

Actualmente tengo

    "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"
      }
    },

y quiero omitir documentos, omitir liberación, devDeps e infra, pero no quiero omitir deps por ejemplo. Porque estoy usando renovar y quiero lanzamientos de parches en fix(deps) .

También tengo habilitado onlyPublishWithReleaseLabel todos modos, por lo que no será un gran problema para mí.

Y una cosa más, ¿está changelogTitle en la etiqueta next dist-tag? Solo pido una aclaración, porque no se muestra en el PR.

@tunnckoCore Creo que su configuración se vería así de la nueva forma:

{
  "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"
    }
  ]
}

El none actúa efectivamente como skip . Pero si realmente necesitara lanzar una actualización de devDep , podría agregar patch y se haría un lanzamiento. Esto difiere de agregar una etiqueta skip , que omitiría el lanzamiento independientemente de otras etiquetas.

changelogTitle

Yo tampoco he hecho esto. Todavía es solo un título. Agregaré esto a mi PR para el refactor (todavía no está en el próximo. Lo sacaré después de changelogTitle)

Correcto. Ok genial :)

El problema se publicó en v8.0.0-next.8

¿Es ahora? Supongo que prerelease s se publican en next ? : pensando: De todos modos, no tengo prisa. Sigo luchando con Yarn v2 + pnp y building / bundling.

editar: ¿Y la falta de title/changelogTitle todavía implica que no se incluirá en una sección en las notas de la versión?

@tunnckoCore hay valores predeterminados en los títulos del registro de cambios según la versión que esté lanzando.

Estoy preguntando por las otras "etiquetas personalizadas" que agregamos desde la configuración y que no se refieren al semver. Si tengo la etiqueta infra sin título, no se agregará, ¿verdad? Y cuando tenga el título (como en devDeps) se agregará.

: rocket: El problema fue lanzado en v8.0.0: rocket:

@adierkens , parece que este problema fue el mayor ímpetu detrás de la revisión principal v8, así que estoy haciendo esta pregunta aquí ... ¿Hay algo especial que deba hacer para actualizar a v8 desde v7.x?

Si tiene labels o skipReleaseLabels adicionales, deberá usar el nuevo formato

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

¡Wooohooo! : tada: Lo intentaré el fin de semana.

En primer lugar, ¡cambios geniales para la v8!

Con respecto a

Los títulos de los registros de cambios se pueden agregar a las etiquetas, pero no está exactamente claro en qué orden tienen prioridad. Si existen etiquetas secundarias y de documentación, ¿qué título del registro de cambios tiene prioridad?

De las pruebas locales, parece que el comportamiento actual es:

• asigne un PR dado a la primera etiqueta con verdadero changelogTitle en orden de prioridad de releaseType ( major , minor , patch , luego todos los demás)
• si el PR tiene múltiples etiquetas asociadas con la misma prioridad releaseType anterior, entonces PR se incluye en la sección de la etiqueta definida en la configuración primero (las etiquetas predeterminadas preceden a todas las demás)

Abajo hay algunos ejemplos:

(1): etiquetas menores y ninguna
config:

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

etiquetas en PR:

minor

sección de etiqueta del registro de cambios: minor

• porque minor releaseType tiene mayor precedencia

(2): múltiples etiquetas de parche
config:

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

etiquetas en PR:

core

sección de etiqueta del registro de cambios: typescript

• porque la etiqueta typescript aparece en la configuración antes de core

(3): ninguna etiqueta y ninguna etiqueta predeterminada
config:

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

etiquetas en PR:

internal

sección de etiqueta del registro de cambios: internal

• porque la etiqueta internal aparece en la configuración antes de typescript (aparece en la configuración predeterminada que tiene la mayor prioridad entre los mismos releaseType

@hipstersmoothie , ¿se pretende el orden de precedencia / comportamiento anterior?

Si es así, sería bueno agregarlo a la documentación para que quede claro cómo se generan las secciones de la etiqueta del registro de cambios y cómo las secciones tienen prioridad (podría ayudar con esto si es necesario)

Si no es así, ¿podemos trabajar para definir un orden de precedencia, ya sea como parte de este tema o de otro?

No lo veo como algo especial o incorrecto. Parece bastante intuitivo. Lo único importante es que major , minor y patch sean siempre los primeros en el registro de cambios, solo porque es algo estándar. Pero incluso si el orden es configurable, también está bien.