Auto: [RFC] Simplifier la configuration des étiquettes

J'aime la première option. c'est un super simple et propre, j'ai du mal à faire la différence entre none et skip . Si je comprends bien, skip n'a aucune incidence sur le journal des modifications et doit être avec une étiquette semver, et none ignorera une version mais créera une entrée unique dans le journal des modifications.

cette méthode élimine la plupart des raccourcis, mais je pense que nous pourrions encore en supporter quelques-uns ?

par exemple, ce qui suit remplacera l'étiquette par défaut major mais héritera également de la description et du changelogTitle

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

ou juste en éditant le titre

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

skip c'est ne pas faire de release. none signifie que le label n'a aucun effet sur la version... donc il peut sortir ou ne pas sortir, selon la présence d'autres labels. Il a besoin d'un meilleur nom.

Donc , sous votre suggestion, les étiquettes par défaut ont des solutions de repli en fonction de ce releaseType est présente? Je pense que cela a du sens.

Donc, selon votre suggestion, les étiquettes ont des solutions de secours par défaut basées sur le type de version présent ? Je pense que cela a du sens.

Ouais

@zephraph Il a besoin d'un meilleur nom.

Je pense que c'est un grand. Il n'y a rien de mieux que de dire "c'est nul car cela n'a aucun impact sur le processus de publication, par exemple corvée/dépendances/quoi que ce soit".

pense que cela a du sens.

Ouais, totalement.

La proposition est géniale.
Je pense que name et chagelogTitle devraient tous deux avoir des valeurs par défaut basées sur le releaseType .

J'ai un PR pour cela maintenant. Il n'aborde pas les points suivants

1. Les titres du journal des modifications peuvent être ajoutés aux étiquettes, mais l'ordre dans lequel ils prévalent n'est pas exactement clair. Si des étiquettes mineures et de documentation existent toutes les deux, quel titre du journal des modifications a préséance ?

2. Logic plupart des validations décrites ici devraient probablement résider dans autobot. Je ne pense pas que l'auto elle-même devrait imposer cela

3. (lié à 1) > Plusieurs étiquettes aucune peuvent être incluses pour ajouter le PR sous différentes sections du journal des modifications

Je ne comprends pas. Comment _"Une étiquette de saut n'est valide que lorsqu'elle est associée à une étiquette semver et est sinon un no-op."_ a du sens ? Si j'ai une étiquette deps ou infra , le type est skip et je veux ignorer pourquoi je dois aussi ajouter une étiquette semver ? Je suppose que je devrais utiliser le none alors, mais cela permet également d'ajouter l'étiquette semver, alors... WAT?! :RÉ

Actuellement j'ai

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

et je veux sauter sur docs, skip-release, devDeps et infra, mais je ne veux pas sauter sur deps par exemple. Parce que j'utilise renovate et que je veux des versions de correctifs sur fix(deps) .

J'ai également activé onlyPublishWithReleaseLabel toute façon, donc ce ne sera pas un gros problème pour moi.

Et encore une chose, est-ce que changelogTitle sur le dist-tag next ? Je demande juste des éclaircissements, car ce n'est pas indiqué dans le PR.

@tunnckoCore Je pense que votre configuration ressemblerait à ceci de la nouvelle manière :

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

Le none agit effectivement comme un skip . Mais si vous aviez vraiment besoin de publier une mise à jour de devDep vous pourriez ajouter patch et une version serait faite. Cela diffère de l'ajout d'une étiquette skip , qui sauterait la version indépendamment des autres étiquettes.

changelogTitre

Je n'ai pas fait ça non plus. Ce n'est encore qu'un titre. Je vais l'ajouter à mon PR pour le refactor (toujours pas sur la prochaine. Je le sortirai après changelogTitle )

À droite. D'accord génial :)

Le problème a été publié dans la version 8.0.0-next.8

Est-ce maintenant? Je suppose que les prerelease sont publiés sur next ? :thinking: De toute façon, je ne suis pas pressé. Toujours en train de se battre avec Yarn v2+pnp et la construction/le regroupement.

edit : Et est-ce que title/changelogTitle manquant implique toujours qu'il ne fera pas de section dans les notes de version ?

@tunnckoCore, il existe des valeurs par défaut sur les titres du

Je pose des questions sur les autres "étiquettes personnalisées" que nous ajoutons à partir de la configuration et qui ne concernent pas le semver. Si j'ai une étiquette infra sans titre, elle ne sera pas ajoutée, n'est-ce pas ? Et quand j'aurai un titre (comme dans devDeps), il sera ajouté.

:rocket: Le problème a été publié dans la v8.0.0 :rocket:

@adierkens , il semble que ce problème ait été l'impulsion majeure derrière la révision majeure de la v8, alors je pose cette question ici... Y a-t-il quelque chose de spécial que je dois faire pour passer de la v8 à la v7.x ?

Si vous avez des labels ou skipReleaseLabels supplémentaires, vous devrez utiliser le nouveau format

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

Woohooo ! :tada: Je vais l'essayer ce week-end.

Tout d'abord, des changements sympas pour la v8 !

Concernant

Les titres du journal des modifications peuvent être ajoutés aux étiquettes, mais l'ordre dans lequel ils prévalent n'est pas exactement clair. Si des étiquettes mineures et de documentation existent toutes les deux, quel titre du journal des modifications a préséance ?

D'après les tests locaux, il semble que le comportement actuel soit :

• attribuer un PR donné à la première étiquette avec le vrai changelogTitle dans l'ordre de priorité des releaseType ( major , minor , patch , puis tous les autres)
• si le PR a plusieurs étiquettes associées à la même priorité releaseType ci-dessus, alors PR est d'abord inclus dans la section de l'étiquette définie dans la configuration (les étiquettes par défaut précèdent toutes les autres)

Ci-dessous quelques exemples :

(1) : étiquettes mineures et aucune
configuration :

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

étiquettes sur PR :

minor

section d'étiquette du journal des modifications : minor

• car minor releaseType a une priorité plus élevée

(2) : plusieurs étiquettes de patch
configuration :

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

étiquettes sur PR :

core

section d'étiquette du journal des modifications : typescript

• car l'étiquette typescript apparaît dans la configuration avant core

(3) : aucune étiquette et aucune étiquette par défaut
configuration :

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

étiquettes sur PR :

internal

section d'étiquette du journal des modifications : internal

• car l'étiquette internal apparaît dans la configuration avant typescript (elle apparaît dans la configuration par défaut qui a la priorité la plus élevée entre le même releaseType

@hipstersmoothie , Le comportement/ordre de priorité ci-dessus est-il prévu ?

Si c'est le cas, il serait bon d'ajouter à la documentation afin qu'il soit clair comment les sections d'étiquette du journal des modifications sont générées et comment les sections ont la priorité (je pourrais aider avec cela si nécessaire)

Si non, pouvons-nous travailler à définir un ordre de préséance, que ce soit dans le cadre de cette question ou d'une autre ?

Je ne le vois pas comme quelque chose de spécial ou de mal. Cela semble assez intuitif. La seule chose importante est que major , minor et patch soient toujours les premiers dans le journal des modifications, simplement parce que c'est un peu standard. Mais même si la commande est configurable, ça va aussi.