Auto: Correctifs - Support des correctifs pour les anciens mineurs et correctifs

@hipstersmoothie
Avez-vous des détails sur la façon dont cela serait mis en œuvre / à quoi cela ressemblerait dans la pratique ?

De plus, je ne suis pas sûr de comprendre ce que signifie merge into a tag ... pourriez-vous éventuellement clarifier ? D'après ce que j'avais compris, vous ne pouviez créer un PR qu'avec une succursale comme cible.

Non, je n'ai pas trop réfléchi au problème.

De plus, je ne suis pas sûr de comprendre ce que signifie la fusion dans une balise

L'interface utilisateur m'a amené à croire que vous pourriez être en mesure de fusionner dans une balise, mais après un examen plus approfondi, cela ne semble pas être possible. Si nous pouvions, cela rendrait cela possible.

En me rappelant un peu, je pense que c'est ce que je pensais:

1. La balise 1.2.3 existe, la version actuelle est 2.0
2. PR est transformé en tag 1.2.3, produit 1.2.3-0 (le 0 est la partie build de semver)

ok, l'utilisation de la partie build de semver est tout à fait logique. ??

S'il n'est pas possible de créer un PR directement sur une balise, ce flux peut nécessiter que les propriétaires de référentiel créent une branche à partir d'une balise sur la branche en amont (branche cible pour PR). Ce serait un peu ennuyeux, mais je ne sais pas s'il y aurait une meilleure alternative. De plus, ces types de versions ne sont probablement pas courants, alors ce serait peut-être ok.

Une approche similaire à l'ancien support majeur ( versionBranches ) pourrait être utilisée où un préfixe de branche pourrait être spécifié dans la configuration. Il semble que cette fonctionnalité soit davantage ciblée sur les versions de type correctif, il est donc peut-être logique de séparer la configuration de l'ancien support majeur. Qu'est-ce que tu penses?

Un exemple de flux peut ressembler à :

• l'utilisateur spécifie dans la configuration automatique de construire en utilisant les identifiants de construction pour les branches avec le préfixe hotfix-
• journal de validation existant
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

Une approche similaire à l'ancien support majeur (versionBranches) pourrait être utilisée lorsqu'un préfixe de branche pourrait être spécifié dans le fichier config.

J'aime l'idée mais dans la pratique, je ne pense pas que ce serait si amusant à utiliser. Étant donné que auto publie beaucoup, vous vous retrouveriez avec un nombre fou de branches.

S'il n'est pas possible de créer un PR directement sur une balise, ce flux peut nécessiter que les propriétaires de référentiel créent une branche à partir d'une balise sur la branche en amont (branche cible pour PR). Ce serait un peu ennuyeux, mais je ne sais pas s'il y aurait une meilleure alternative. De plus, ces types de versions ne sont probablement pas courants, alors ce serait peut-être ok.

Je suis d'accord que ce type de libération est hors de la norme. qui rend la création de succursale automatisée moins utile. Vous obtiendriez beaucoup de bruit (plus de branches) sans les utiliser autant, voire jamais.

Quant au flux proposé ci-dessus, cela semble bien fonctionner. C'est dommage que nous ne puissions pas transformer les PR en tags ! rendrait ce flux de travail plus facile.

En y réfléchissant, cette fonctionnalité aura probablement besoin de quelques éléments dans auto pour être complètement étoffée :

1. Nouvelle commande auto hotfix : lors de son exécution, le projet sera publié avec une nouvelle version de correctif basée sur la dernière balise de la branche
2. Nouvelle fonctionnalité pour auto shipit : Détecter si nous sommes dans un hotfixBranch et exécuter auto hotfix

Quant à la façon dont auto hotfix devrait fonctionner, cela pourrait aller :

1. le chemin de next ou canary => Nouveau hook qui permet au plugin de contrôler la façon dont le correctif est publié, qu'il soit pris en charge ou non
2. réutiliser les crochets version et publish et les rendre capables de libérer build semver

Des deux options, je pense que je penche vers 1 car appeler les crochets version et pubish d'une nouvelle manière pourrait être considéré comme un changement décisif. L'inconvénient est que certains des crochets ne s'appelleront pas afterVersion ce qui fait que certains plugins ne fonctionnent pas. C'est actuellement un problème pour les canary et next . car ils n'appellent pas ce crochet non plus. Donc quelque chose qui n'a pas besoin de s'inquiéter immédiatement.

Êtes-vous intéressé à essayer d'ajouter ceci?

J'aime l'idée mais dans la pratique, je ne pense pas que ce serait si amusant à utiliser. Étant donné que l'auto libère beaucoup, vous vous retrouveriez avec un nombre fou de branches.

oops, cela signifiait qu'il était similaire à l'ancien support majeur en termes de configuration de préfixe de branche. Tout à fait d'accord pour dire que la création automatique de branches créerait trop de bruit, en particulier avec des relâchements fréquents,

En pensant à cela, cette fonctionnalité aura probablement besoin de quelques éléments en auto pour être complètement étoffée :

1. Nouveau correctif automatique de commande : lors de son exécution, le projet sera publié avec une nouvelle version de correctif basée sur la dernière balise de la branche
2. Nouvelle fonctionnalité pour l'expédition automatique : Détectez si nous sommes dans une branche de correctif et exécutez le correctif automatique

Ouais. Je pense que cela résumerait en grande partie les changements requis.

Quant à la façon dont le correctif automatique devrait fonctionner, cela pourrait être :

1. the way of next ou canary => Nouveau hook qui permet au plugin de contrôler comment le correctif est publié s'il est pris en charge du tout
2. réutiliser la version et publier les crochets et les rendre capables de publier le serveur de build

Sur les deux options, je pense que je penche vers 1 car appeler la version et les crochets de publication d'une nouvelle manière pourrait être considéré comme un changement décisif. L'inconvénient est que certains des crochets ne seront pas appelés afterVersion, ce qui empêchera certains plugins de fonctionner. C'est actuellement un problème pour Canary et pour le suivant. car ils n'appellent pas ce crochet non plus. Donc quelque chose qui n'a pas besoin de s'inquiéter immédiatement.

De haut niveau, je pense que 1 a également du sens. J'aurais besoin de parcourir le code pour mieux comprendre quels crochets sont appelés pour quelle commande, mais si next , canary , & hotfix suivent tous des modèles similaires, alors tous les points douloureux seraient probablement plus faciles à résoudre plus tard.

Êtes-vous intéressé à essayer d'ajouter ceci?

Bien sûr, j'en serais ravi.
Je ne pourrai probablement pas jeter un œil à la mise en œuvre de cela avant la semaine prochaine, mais je suppose que ce n'est pas grave car ce problème n'a pas été mis à jour depuis mars.

Impressionnant! Pas de travaux prévu sur celui-ci donc c'est tout toi

FWIW - J'allais essayer de construire ceci comme un plugin en faisant exactement ce que vous considériez comme un choix inférieur - faire une branche version-MAJOR-MINOR . Cela ne ressemble pas à trop de bruit sur notre processus actuel, TBH. Nous créons déjà des branches pour chaque ligne de version.

Une grande partie de versionBranches ce moment est ce plugin :

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

Il semble trivial d'ajouter la prise en charge de SEMVER.minor , mais j'admets que je ne sais pas ce que d'autres parties de l'auto doivent peut-être changer.

Cela fait partie de ce qui se passe pour l'ancienne version, mais cette vérification dans shipit doit également réussir

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

Ce qui va ensuite ici et remplace simplement l'endroit où commencer à calculer la version à partir de

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

La seule considération que nous devons faire avec l'ancien mineur/patch et non majeur est la non-concordance de version potentielle. Avec les mineurs, c'est probablement moins un problème cependant

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

Alors peut-être que la commande hotfix n'est pas nécessaire. Au lieu de cela, il pourrait simplement essayer de numéro de version unique. Cependant, il devrait peut-être y avoir une certaine validation à ce sujet.

Règles :

1. impossible de publier une version majeure sur une ancienne branche de version mineure/patch (obligatoire)
2. ne peut pas publier de mineur sur une ancienne branche de version de correctif (peut-être inutile ?)

@hipstersmoothie
Savez-vous quel est le comportement par défaut maintenant si vous avez configuré ci pour construire à partir d'une ancienne balise, où la prochaine balise n'est pas disponible ?

Je suppose qu'il y aurait un échec, bien que je ne sache pas où cette erreur se produirait (peut-être lors de la poussée de la balise ?).

c'est à dire:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

En dehors de l'application des règles spécifiées par @hipstersmoothie , je vois un problème potentiel / une confusion avec la stratégie / la mise en œuvre de try to unique version number . Pour l'exemple donné par @hipstersmoothie , v1.1.2 serait considéré par d'autres comme une version de correctif de v1.1.1 , mais comme le développement n'était pas linéaire, ce n'est pas garanti. Potentiellement, il pourrait même y avoir un changement rétrocompatible de v1.1.1 à v1.1.2 car il est probable que v1.1.2 n'ait pas les changements de v1.1.1 . Cela pourrait devenir exacerbé et plus déroutant si la prochaine version unique est plus éloignée de v1.1.0 (c'est-à-dire : et si la prochaine version unique est v1.1.100 ?)

L'utilisation de la partie des métadonnées de construction de semver limiterait cette confusion car, selon les spécifications de semver, elle est ignorée lors du calcul de la priorité des versions. Si vous incrémentez le numéro de métadonnées de construction, alors peut-être que commit sha pourrait être utilisé à la place d'un numéro d'incrémentation.

En général, le développement logiciel n'est pas nécessairement linéaire, donc pas sûr qu'il y ait une meilleure implémentation.

Si nous voulons généraliser, nous pourrions peut-être avoir une sorte de configuration ou de hook pour spécifier la stratégie ci-dessus, quelle que soit la branche (ou branch pourrait être un paramètre à hooker).
De cette façon, différentes implémentations pourraient être utilisées via des plugins.

Savez-vous quel est le comportement par défaut maintenant si vous avez configuré ci pour construire à partir d'une ancienne balise, où la prochaine balise n'est pas disponible ?

Généralement, les balises ne se construisent pas car le commit a [skip ci] dans le message

Cela pourrait devenir exacerbé et plus déroutant si la prochaine version unique est plus éloignée de la v1.1.0

Ceci est un excellent point. Fait définitivement de la partie des métadonnées de construction de la version la bonne stratégie.

Si nous voulons généraliser, nous pourrions peut-être avoir une sorte de configuration ou de hook pour spécifier la stratégie ci-dessus, quelle que soit la branche (ou branch pourrait être un paramètre à hooker).
De cette façon, différentes implémentations pourraient être utilisées via des plugins.

votre message m'a à peu près convaincu que trouver une balise unique est un schéma déroutant et que nous ne devrions probablement pas le faire.

Peut-être que si nous faisons un mix, cela pourrait fonctionner. Les correctifs et les anciens mineurs devraient être faciles. Cela pourrait fonctionner exactement de la même manière que oldVersionBranches pour les majors :

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

Ensuite, nous n'avons qu'à faire la partie des métadonnées de construction pour appliquer les correctifs.

Avec les options from et useVerion fusionnées, existe-t-il un moyen intégré de faire un correctif ? Je devais juste en faire un aujourd'hui et j'ai choisi de le faire manuellement.

Pour le contexte, mon projet est sur 7.7. Un grand consommateur de notre projet publie actuellement une version qui est sur 7.5, a trouvé un problème et nécessitait 7.5.1 afin qu'ils n'aient pas eu à tout re-QA à mi-parution. Pas optimal, mais cela arrive occasionnellement.

Toujours pas moyen de le faire à ma connaissance sans intervention manuelle. Je pense que quelqu'un en interne chez Intuit prévoit d'ajouter cela éventuellement. Je suis d'accord que c'est une fonctionnalité qui manque cruellement dans l'auto

Génial à entendre ! Merci

Nous (moi et @10hendersonm) avons développé une solution pour cela mais c'est assez
impliqué. Cependant, il utilise uniquement l'auto et les plugins !

Nous venons de corriger 7.2.1, 8.1.1 et 8.2.2 de notre projet en utilisant uniquement des PR
(très soigneusement).

Nous pourrions examiner comment partager cela si les gens sont intéressés ?

Le jeu. 14 janvier 2021, 19 h 27, Matt Felten [email protected] a écrit :

Génial à entendre ! Merci

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

je serais très intéressée !

Bonjour à tous! Je suis intéressé à contribuer à cela. Ma proposition est la suivante :

1. En général, auto tentera de respecter toutes les branches version-* . Par exemple, une fusion de correctifs de n'importe quelle branche dans version-1.1.4 générera une version de la version 1.1.5 . Si cette version a déjà été créée, la version NPM ou la balise Git échouera, mais il s'agit d'un cas d'erreur normal et attendu.
2. Nous pouvons mettre versionBranches jour "major" | "minor" | "patch" , ce qui générera des branches de correctifs potentielles en fonction de ce que vous spécifiez. Cela vous permet de choisir le compromis entre avoir besoin de créer manuellement une branche version-* et se retrouver avec beaucoup trop de branches à maintenir lorsque vous n'avez pas besoin de correctifs

Les pensées?

mais c'est un cas d'erreur normal et attendu\

Je m'attendrais toujours à ce que cela crée un certain type de version. J'ai récemment eu un cas où je voulais publier un correctif à partir d'un commit spécifique afin de ne rien extraire d'autre. Je pense que dans ce cas, nous pourrions utiliser la partie build de semver de la conversation ci-dessus.

Nous pouvons mettre à jour la versionBranches pour accepter "majeur" | "mineur" | "pièce"

La configuration actuelle peut être soit true soit une chaîne avec laquelle préfixer les branches principales. Je pense que la nouvelle configuration devrait ressembler à quelque chose comme

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

La dernière question à laquelle il faut répondre est toujours le hook de correctif ou appelez les hooks version+publish en regardant le code de l'implémentation actuelle de la branche de l'ancienne version, nous faisons l'option 2 et appelons version+publish (et je pense que cela publie par erreur dans la dernière balise).

@lshadler Nous avons beaucoup besoin de nous associer à cela pendant un petit moment pour trouver la meilleure approche.

@bmuenzenmeyer Peux-tu donner un aperçu de ta démarche ?

Plus je pense à la mise en œuvre, plus je pense que cela nécessitera la v11 et plus de contexte ajouté à la version et aux commandes de publication.

Pour les anciennes versions, nous avons besoin du dernier pipeline complet à exécuter avec le journal des modifications, afterVersion et tous ou leurs crochets appelés lors d'une dernière version.

Nous devrions probablement faire en sorte que les prochaines versions aient la même version après la publication de la dernière version du flux de publication. Cela peut aussi faire partie de la v11. Il doit correspondre au dernier flux de travail afin que vous puissiez ajouter une automatisation similaire.

Le flux de travail Canary peut rester le même car rien n'est engagé pour un canari et vous pouvez déjà simplement appuyer sur le crochet canari pour faire plus de choses.

Bonjour à tous, avec la folie de cette dernière année, malheureusement ce problème m'a échappé.

En ce qui concerne les différentes approches, je pense qu'il peut être utile de considérer les différents cas d'utilisation pour lesquels ces fonctionnalités résolvent. À mon avis, je peux voir 2 cas d'utilisation :

• (1) support à long terme pour une ancienne branche (c'est-à-dire: ancienne version majeure)
• (2) support à court terme pour une version spécifique (c'est-à-dire : correctif)

Sur la base de cette conversation, je pense qu'il est logique d'avoir des approches distinctes pour chacun de ces cas d'utilisation.

(1) Pour le support à long terme d'une branche / piste de version, je pense que versionBranches devrait être capable de résoudre. S'il y a un désir d'étendre ce comportement pour les versions mineures (comme quelques-uns l'ont mentionné ci-dessus), cela pourrait être une amélioration de cette fonctionnalité.

(2) Pour le support / correctif à court terme, basé sur les threads ci-dessus, je pense qu'il devrait y avoir un moyen standard pour les utilisateurs de toujours utiliser la partie build de semver pour générer une version de correctif. Cela donne un comportement cohérent pour les propriétaires de code à utiliser et évite quelques scénarios de cas compliqués. Pour ce cas, je pense qu'une nouvelle commande de correctif et un nouveau hook pourraient être utilisés. Cela pourrait être une amélioration distincte. En général, ce cas d'utilisation devrait être relativement rare car les consommateurs devraient être encouragés à utiliser la dernière version si possible.

edit _(Pour le cas d'utilisation à court terme, la configuration de versionBranches pourrait être étendue pour autoriser un paramètre / bascule / indicateur qui indique s'il faut honorer les étiquettes semver pour les branches version- ou toujours utiliser la partie build de semver et ignorer les étiquettes pour ces branches)_

Y a-t-il d'autres cas d'utilisation que ces 2 qui devraient être pris en compte ?

Faut-il envisager différentes approches pour différents cas d'utilisation ?

(de plus, je peux toujours aider avec certains de ces changements, mais je ne veux certainement pas empêcher quelqu'un d'autre d'apporter des modifications pour cela)

aussi, une pensée tangentielle pour les motifs de branchement :

auto générera une balise git (release) pour les versions. Cela signifie qu'une référence git valide est transmise à github. Pour le cas d'utilisation du support à court terme (c'est-à-dire : branche à courte durée de vie/branche de correctif), cela signifie qu'un utilisateur peut supprimer la branche à courte durée de vie après qu'une balise release/git a été poussée.

• étant donné une branche principale avec les balises suivantes
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

Pour les branches de courte durée, il peut être utile de documenter le motif de branchement ci-dessus lors de l'ajout d'une fonctionnalité. J'ai personnellement constaté que beaucoup ne savent pas que vous pouvez supprimer la branche et avoir toujours une référence au nouveau commit, ce qui peut aider différents projets à réduire l'encombrement des branches de courte durée.

Je jouais récemment avec du code pour utiliser la partie build de semver pour créer des builds. Ce faisant, je suis tombé sur le cas d'utilisation où la dernière version de github n'était pas nécessairement la version sémantique la plus récente/la plus élevée.

Par exemple, dans l'exemple mentionné ici : https://github.com/intuit/auto/issues/1054#issuecomment -780286683, la dernière version de github s'afficherait sous la forme v1.2.3+1 car elle a été créée temporairement après la plus haute version version sémantique : v1.3.0 .

Étant donné que de nombreux endroits dans le code font référence à getLatestRelease , cela peut entraîner des comportements variés si le pipeline ne définit pas explicitement le paramètre from . c'est à dire:

• ce qui est inclus dans les notes de version
• ce que la version précédente est calculée comme
• fonctionnalité potentiellement cassante si la dernière version de github n'est pas accessible depuis le commit HEAD

Je n'ai pas testé, mais je pense que ces types de scénarios seraient également accessibles via le comportement versionBranches existant. Je pense que cela est lié au commentaire concernant les flux qui doivent générer des balises git / des versions de github :

La dernière question à laquelle il faut répondre est toujours le hook de correctif ou appelez les hooks version+publish en regardant le code de l'implémentation actuelle de la branche de l'ancienne version, nous faisons l'option 2 et appelons version+publish (et je pense que cela publie par erreur dans la dernière balise).

En termes de résolution, ce problème peut probablement être résolu indépendamment de la refactorisation du hook en remplaçant la logique getLatestRelease par :

• (1) récupérer les versions de github à l'aide de listReleases , puis trier pour trouver la version la plus élevée (pas de préversion ou de build) accessible
• (2) ou récupérer les balises git, puis trier pour trouver la version la plus récente (pas de pré-version ou de build) accessible

La différence ici serait de savoir si auto considère les versions de github ou les balises git comme source de vérité, ce qui est lié à la discussion https://github.com/intuit/auto/discussions/1867#discussioncomment -684192.

Je pencherais d'abord vers (2), comme

• (a) nous sommes finalement après la git ref (tag) et non les autres éléments de la version github
• (b) cela réduirait le nombre d'appels sur le réseau

@hipstersmoothie ,
Si nous devons modifier la logique getLatestRelease , que pensez-vous (1) de l'utilisation des versions github vs (2) de l'utilisation des balises git vs (3) autre chose ?

Oui, pour que l'auto multi-paquets fonctionne, il faudra refactoriser toutes les dernières versions de GitHub en juste des balises. 2 est def l'option à utiliser pour faire ce travail.