Auto: Plusieurs plugins de gestionnaire de packages dans 1 dépôt

En y réfléchissant un peu plus, il serait probablement plus logique d'introduire une nouvelle option de configuration de haut niveau.

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

Pour ce faire, je pense que nous pourrions utiliser des fonctions d'itération pour exécuter shipit sur plusieurs choses et générer le même nombre de commits

ex pour le dernier :

1. courir tout en même temps
2. rendement avant de valider le journal des modifications
3. commit changelog en une seule fois
4. rendement jusqu'à ce que la version soit dépassée
5. valider la version si nécessaire
6. courir jusqu'à la fin

Avec cette configuration, vous pourriez vraiment sauter sur lerna tous ensemble

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

Si aucun commit ne correspond à un package aucune release ne sera effectuée. Cela permet une gestion indépendante du monorepo d'une manière beaucoup plus simple et sans lerna . Si vous voulez une version fixe monorepo, la voie classique serait la solution.

Une autre fonctionnalité intéressante est que vous pouvez avoir deux projets leran dans votre référentiel avec différents schémas de version ( fixed et independent )

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

Cela signifie que vous pouvez utiliser le plugin chrome-web-store le plugin npm dans un seul référentiel.

Je suppose que vous voulez dire que vous ne pouvez pas utiliser les deux dans le même projet ?

Chaque plugin effectue actuellement des commits, des balises et des push. cela ferait beaucoup de bruit. devrait probablement déplacer ces actions git vers le noyau afin que cela ne se produise qu'une seule fois ? bien que vous souhaitiez peut-être des commits séparés pour chaque package.

Il peut être judicieux d'adopter une approche hybride. Peut-être que chaque plugin s'engage, mais on ne pousse qu'une seule fois ?

Je ne sais pas vraiment comment les balises fonctionneraient dans le monde où chaque dossier est sa propre version emballée. Créez-vous un tag pour chaque version que vous créez ? Vous en faites un à la fin ?

En y réfléchissant un peu plus, il serait probablement plus logique d'introduire une nouvelle option de configuration de haut niveau.

J'aime l'idée de pouvoir personnaliser l'expérience de publication par package. Peut certainement voir certains avantages à pouvoir gérer un déploiement s3/gh-pages pour un package docs rapport à vos packages de bibliothèque.

Une chose à gérer est l'inclusion d'un package dans plus d'un pipeline de publication. Que se passe-t-il en cas de :

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

Le package chrome-ext est-il publié à la fois sur npm _et_ sur webstore ? Ou est-ce que la version npm gagnante parce qu'elle est déclarée en premier ?

Je ne sais pas vraiment comment les balises fonctionneraient dans le monde où chaque dossier est sa propre version emballée. Créez-vous un tag pour chaque version que vous créez ? Vous en faites un à la fin ?

Je pense que nous pouvons faire correspondre le comportement de Lerna. juste beaucoup de balises sur un commit. chaque balise devient alors sa propre version

Le package chrome-ext est-il publié à la fois sur npm et sur la boutique en ligne ? Ou la version npm gagne-t-elle parce qu'elle est déclarée en premier ?

Dans ce cas oui, il essaierait de faire les deux. Mais c'est juste une mauvaise configuration. Vous pouvez l'utiliser comme fonctionnalité et dire publier un package dans deux registres différents (ex: npm et registre de packages github)

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

Cela semble intéressant... et compliqué 😅

Je suis généralement avec la configuration plutôt que d'essayer d'être trop intelligent avec la détection (car cela peut tomber en panne de manière inattendue et être difficile à tester).

Je suppose que ma première question est à quoi ressemble l'état par défaut de cela. Si vous n'avez qu'un plugin npm , avez-vous besoin d'ajouter une configuration avant qu'il ne fonctionne ? Même question avec les autres.

En ce qui concerne l'interaction git, il me semble que les interactions git devraient généralement faire partie du pipeline du plugin. Si un plugin a besoin de faire un commit, il devrait juste pouvoir puiser dans un hook capable de commit. Le push ne devrait probablement être géré que dans le noyau, car cela a des implications sur des éléments tels que le fonctionnement de CI.

Si vous n'avez qu'un plugin npm, avez-vous besoin d'ajouter une configuration avant qu'il ne fonctionne ?

La configuration qui fonctionne aujourd'hui devrait fonctionner dans le monde packages . Donc aucun changement nécessaire. La plupart des changements de rupture seraient du côté de l'API du nœud et ne seraient pas visibles pour les utilisateurs normaux.

Si un plugin a besoin de faire un commit, il devrait juste pouvoir puiser dans un hook capable de commit.

J'aime cette idée. Formaliser cette interaction git dans auto est probablement utile. Et s'ils n'utilisent pas ce crochet, cela signifie juste un peu plus de bruit (ex: un commit supplémentaire et un push supplémentaire)

Je réfléchissais également à la façon d'utiliser Auto avec un monorepo et j'ai proposé une approche légèrement différente qui pourrait répondre à vos besoins.

Fondamentalement, si vous avez un monorepo, vous pouvez avoir plusieurs sous-répertoires qui ont chacun leur propre fichier .autorc qui peut configurer les plugins dont chaque sous-projet aurait besoin.

Vous pouvez alors choisir d'avoir un préfixe différent pour chaque projet afin que chaque projet puisse être publié à des moments différents si besoin est. Par exemple, une version de sub-project1 pourrait être étiquetée avec sub-project/v1.4.5 et un autre projet obtiendrait l'étiquette sub-project2/v9.9.9

Auto peut ensuite utiliser quelque chose comme git describe --tags --matches "sub-project1/*" pour obtenir et mettre à jour les balises pour chaque projet en conséquence.

Juste une pensée.

C'est en fait assez proche de l'approche que j'ai adoptée. j'ai
travaillé là-dessus cette semaine.

J'ai dû ajouter ce drapeau à certaines des commandes jusqu'à présent (—matches) et
ça s'est plutôt bien passé.

J'ai opté pour l'approche terrain des « packages » et c'est fondamentalement juste et
tableau de "autorc"

Pour obtenir le préfixe, j'ai ajouté un crochet pour les plugins afin de fournir un nom. Cette
aidera également à signaler à l'auto si le plugin est compatible avec plusieurs packages

Le mer. 29 janv. 2020 à 21:11 Alejandro Barrientos <
[email protected]> a écrit :

Je réfléchissais aussi à la façon d'utiliser Auto avec un monorepo et j'ai proposé
une approche légèrement différente qui peut fonctionner pour votre besoin.

Fondamentalement, si vous avez un monorepo, vous pouvez avoir plusieurs sous-répertoires
qui ont chacun leur propre fichier .autorc qui peut configurer n'importe quel plugin
chaque sous-projet aurait besoin.

Vous pouvez alors choisir d'avoir un préfixe différent pour chaque projet afin que
chaque projet peut être publié à des moments différents si besoin est. Par exemple un
la version du sous-projet1 pourrait être étiquetée avec sous-projet/v1.4.5 et
un autre projet obtiendrait le tag sub-project2/v9.9.9

Auto peut alors utiliser quelque chose comme git describe --tags --matches
"sub-project1/*" pour obtenir et mettre à jour les balises pour chaque projet en conséquence.

Juste une pensée.

-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJZcom#PDN5WWW86GOI
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

En revenant et en relisant ceci, je suis en fait assez excité! Les multiples balises préfixées avec le nom du package sonnent vraiment bien. De plus, j'aime beaucoup le champ packages .

@hipstersmoothie existe-t-il aujourd'hui un moyen simple de publier des registres à 2 npm avec shipit, que vous avez vu ? ou certaines fonctionnalités basculent en mode automatique dont je n'ai pas une bonne vue d'ensemble pour le moment.

@vincentbriglia est- ce qu'un plugin qui publie sur le package GitHub fonctionnerait ? il pourrait à peu près se greffer sur le plugin npm. Ce serait facile pour les versions next et latest , les canaris n'ont pas autant de sens. Les pensées?

@hipstersmoothie, nous avons un cas où nous publions le même package dans le registre NPM et le registre GHPR. La raison ici est que le GHPR, même s'il est annoncé comme tel, ne proxy pas correctement les packages. Le problème sous-jacent étant que nous avons la même portée sur npm et github.

Nous développons principalement à huis clos, nous utilisons les builds Canary pour avoir des conversations/approbations avec notre équipe de conception à partir de feature branches > next donc les builds Canary sont toujours utiles pour nous dans ce contexte. Le plugin npm fournit actuellement cette fonctionnalité donc il serait dommage de la perdre.

Je suppose que le contexte de l'utilisation de GHPR est généralement qu'il s'agit du principal emplacement de publication dans le contexte "d'organisation" privé et que si un composant doit être rendu public, npmjs.org est secondaire. (Je n'ai vu personne installer de composants publics à partir de github). Dans le contexte open source, il s'agit généralement de npmjs, pas de GHPR ou d'un autre registre de packages privé.

en passant, puisque vous mentionnez un plugin GHPR spécifique: nous avons réservé du temps pour la semaine prochaine pour créer un plugin automatique qui supprimerait les versions de package en fonction de certaines règles (les organisations sont limitées à 50 Go de packages, et cela inclut docker images)

• supprimer le dernier canari à portée
• supprimer le nième dernier suivant dans la plage
• ...

J'attendrais également avec plaisir que vous créiez un éditeur de ghpr spécifique jusqu'à ce que le travail commence sur la v10, les idées présentées ici semblent très excitantes et sont peut-être plus "à l'épreuve du temps".

nous pourrions vivre sans publier en même temps public et privé pour le moment, mais au moins vous savez que c'est mon cas d'utilisation.

Je pensais plutôt à un plugin "registre de paquet secondaire". Ainsi, le plugin npm fonctionnerait comme il le fait, en publiant sur n'importe quel registre configuré. Ensuite, ce nouveau plugin serait publié dans un deuxième registre (qu'il s'agisse de npm ou de ghpr n'a pas d'importance) en libérant toutes les versions du commit HEAD.

en passant, puisque vous mentionnez un plugin GHPR spécifique: nous avons réservé du temps pour la semaine prochaine pour créer un plugin automatique qui supprimerait les versions de package en fonction de certaines règles (les organisations sont limitées à 50 Go de packages, et cela inclut docker images)

Cela semble être une bonne fonctionnalité. Je ne savais pas que ces limites existaient !

ce nouveau plugin publierait dans un deuxième registre (que ce soit npm ou ghpr n'a pas d'importance) libérant toutes les versions du commit HEAD

eh bien cela fonctionnerait certainement! edit : aussi pour notre(nos) scénario(s)

Salut! Quel est l'état actuel d'Auto par rapport à ce fil ? Est-il possible de publier plus d'une chose à partir de la même version ?

puisque chaque plugin de gestionnaire de packages repose sur un fichier supplémentaire pour le gestionnaire de packages (tous sauf git-tag )

Je pense que c'est une fausse hypothèse. Le plugin docker repose-t-il sur n'importe quel fichier ? Cela pourrait être inutile pour cela, alors c'est peut-être un mauvais exemple. En voici un autre alors: je suis intéressé par l'utilisation d'Auto avec sbt (l'outil de construction le plus courant pour Scala) et il n'a aucune configuration JSON/XML lisible par machine. Une version sbt est configurée avec le code Scala et pour extraire toute information sur la version dont vous auriez besoin pour communiquer avec sbt d'une manière ou d'une autre.

Cela permet une gestion indépendante du monorepo d'une manière beaucoup plus simple

Il semble également d'après ce fil que l'objectif est d'accueillir des projets monorepo avec plusieurs sous-projets qui ont des besoins de publication différents. Qu'en est-il d'un projet unique qui produit différents types d'artefacts ? Par exemple une image Docker et une archive de configuration (à télécharger quelque part). Ou une action GitHub qui peut être publiée en tant que bibliothèque sur NPM et en tant qu'action sur les versions GitHub.

Chaque plugin effectue actuellement des commits, des balises et des push. cela ferait beaucoup de bruit. devrait probablement déplacer ces actions git vers le noyau afin que cela ne se produise qu'une seule fois ? bien que vous puissiez _vouler_ des commits séparés pour chaque package .

Je pense que c'est le principal problème avec l'implémentation actuelle des plugins. Cela revient à ma confusion au sujet de l'affirmation selon laquelle chaque commande "ne fait qu'une chose vraiment bien". À mon avis, le crochet publish devrait vraiment _publier_ uniquement pour le gestionnaire de paquets donné, pas créer de commits ou pousser des balises git. Si chaque plugin de publication peut se concentrer uniquement sur la mise en œuvre de ses spécificités de gestionnaire de packages, les parties communes du processus peuvent être réutilisées et/ou partagées. Est-il encore possible d'y parvenir avec Auto ou est-ce trop biaisé en faveur des projets de type NPM ?