Auto: "auto canary" en monorepo avec la version bêta échoue

Créé le 27 sept. 2019  ·  14Commentaires  ·  Source: intuit/auto

Décrivez le bogue

Lors de l'exécution de auto canary dans un monorepo Lerna, plusieurs problèmes apparaissent.

  1. La version passe de 9.0.0-beta.33 à 9.0.1-canary.809.1.1a2be58f.0 alors qu'elle devrait être 9.0.0-canary... place.

  2. Il dit Error: Running command 'npx' failed juste au début

  3. Il ne parvient pas à publier sur npm, en disant You cannot publish over the previously published versions: 9.0.0-beta.33

Le PR que j'essaie de publier est : https://github.com/react-spring/react-spring/pull/809

Reproduire

Je n'ai pas encore de repro minimal. LMK si c'est nécessaire.

Comportement prévisible

Tous les packages devaient être publiés avec 9.0.0-canary.809.1.1a2be58f.0 comme version.

Bureau (veuillez compléter les informations suivantes) :

  • Système d'exploitation : macOS v10.14.5
  • Navigateur : N/A
  • Version : v7.6.0

Contexte supplémentaire

GH_TOKEN="xxx" auto canary --build 1 --pr 809
Error: Running command 'npx' failed


Changes:
 - @react-spring/addons: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/animated: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/core: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - react-spring: 9.0.0-beta.34 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/shared: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/konva: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/native: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/three: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/web: 9.0.0-beta.34 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/zdog: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0



lerna notice cli v3.15.0
lerna info current version 9.0.0-beta.34
lerna WARN force-publish all packages
lerna info Assuming all packages changed
lerna WARN version Skipping working tree validation, proceed at your own risk
lerna info auto-confirmed 
lerna info execute Skipping git tag/commit
lerna info execute Skipping git push
lerna info execute Skipping releases
lerna info publish Publishing packages to npm...
lerna notice Skipping all user and access validation due to third-party registry
lerna notice Make sure you're authenticated properly ¯\_(ツ)_/¯
lerna http fetch PUT 403 https://registry.npmjs.org/@react-spring%2fshared 1475ms
lerna ERR! E403 You cannot publish over the previously published versions: 9.0.0-beta.33.

    at ChildProcess.<anonymous> (~/.nvm/versions/node/v11.10.1/pnpm-global/3/node_modules/.pnpm/registry.npmjs.org/@auto-it/core/7.6.1/node_modules/@auto-it/core/dist/utils/exec-promise.js:98:36)
    at ChildProcess.emit (events.js:197:13)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:254:12)
bug

Tous les 14 commentaires

De plus, le champ publishConfig.directory dans le package.json chaque package n'est pas respecté.

Je vais regarder ça !

  1. La version passe de 9.0.0-beta.33 à 9.0.1-canary.809.1.1a2be58f.0 alors qu'elle devrait être 9.0.0-canary... à la place.

J'ai ouvert le numéro 609 pour me débarrasser du hachage supplémentaire qu'il contient. La partie .0 de la version est due au drapeau --preid . Nous en avons besoin pour le reste de la version afin que cela ne puisse pas vraiment disparaître.

@hipstersmoothie Oh, je ne me plaignais pas de ça. Je ne voulais juste pas prendre le temps de taper le hachage. 😆 Cette phrase indique en fait comment c'est 9.0.1 alors qu'il devrait toujours être 9.0.0 .

Ah, je vois. Dans ce cas, c'est le comportement attendu. La version canari est la version "suivante" simulée. Par exemple:

PR a l'étiquette major => Le canari avec ces changements contient ces changements majeurs et devrait être une nouvelle version majeure

La raison pour laquelle il est passé à 9.0.1 est que nous utilisons par défaut un patch lorsqu'aucune étiquette n'est trouvée.

Ah d'accord. La balise latest pointe actuellement vers 8.0.27 , donc je ne m'attendrais pas à ce que auto canary utilise 9.0.1 toute façon. Il a dû être confondu par l'existence de 9.0.0-beta.33 . Existe-t-il un moyen de forcer la version à rester à 9.0.0 ?

La façon dont il se comporte actuellement est qu'il examinera la "dernière version" et votre version locale et utilisera la version supérieure. Donc, dans ce cas, cela a été résolu en 9.0.0-beta.33 .

Existe-t-il un moyen de forcer la version à rester à 9.0.0 ?

Localement, si je lance lerna avec prerelease au lieu de preminor la version ne s'incrémente pas. Pour obtenir prerelease à la commande canary, nous pourrions ajouter un indicateur supplémentaire ou utiliser une étiquette prerelease , mais la fonctionnalité ne serait pas automatique.

Il ne parvient pas à publier sur npm, indiquant que vous ne pouvez pas publier sur les versions précédemment publiées : 9.0.0-beta.33

Cela semble être un problème lorsque les package.json dans le dossier dist . L'étape prepare est exécutée avant tout ce qui se fait automatiquement, donc la version est celle qui était là au début. Dans ce cas "9.0.0-beta.33"

Lorsque lerna s'exécute, il récupère cette version obsolète du package.json , qui contient une version déjà publiée, et essaie de la publier à nouveau.

Localement, si je lance lerna avec prerelease au lieu de preminor la version ne s'incrémente pas. Pour obtenir prerelease à la commande canary, nous pourrions ajouter un indicateur supplémentaire ou utiliser une étiquette prerelease , mais la fonctionnalité ne serait pas automatique.

Cela devrait suffire. Considérez-vous « exécuter auto canary localement à partir d'une branche qui s'appuie sur une version beta / next » comme un cas limite ? Sinon, il devrait peut-être y avoir un support automatique ici. De plus, si je devais exécuter auto canary partir de CI, aurais-je toujours ce cas limite ?

Lorsque lerna s'exécute, il récupère cette version obsolète du package.json , qui contient une version déjà publiée, et essaie de la publier à nouveau.

Lerna prend en charge publishConfig.directory (voir ici ), mais peut-être que votre intégration avec Lerna évite en quelque sorte ce chemin de code.

C'est cette ligne qui pose problème.

Parce que vous faites cette chose où vous copiez sur le package.json, readme, etc dans le dossier dist puis simplement publier, nous avons besoin pour exécuter le prepare script à un moment très précis:

  1. lerna version - change package.json en version Canary
  2. prepare - package final placé dans le dossier dist
  3. lerna publish - publie le dossier dist de paquet avec la version correcte

Donc, pour ce workflow, vous devez laisser les scripts de cycle de vie s'exécuter et ignoreScripts doit être défini sur false (ou tout simplement pas du tout).

Considérez-vous "l'exécution d'Auto Canary localement à partir d'une branche qui s'appuie sur une version bêta/prochaine" comme un cas limite ? Sinon, il devrait peut-être y avoir un support automatique ici.

Le support bêta/suivant n'est pas encore vraiment intégré, mais je reviendrai sur ce problème lorsque j'essaierai de le résoudre.

peut-être que votre intégration avec Lerna évite en quelque sorte ce chemin de code.

Nous ne faisons aucune hypothèse sur l'utilisation de lerna, donc cela ne devrait pas vraiment être un problème. Vous pouvez voir ici que nous appelons juste lerna pour faire tout le gros du travail.

@aleclarson J'ai pu publier un canari après avoir supprimé ignoreScripts . Je pense avoir tout réglé dans ce problème, si c'est le cas, veuillez fermer !

D'accord ma douce ! J'ai une solution de contournement en place en ce moment, donc je ne vérifierai pas de sitôt.

Je ne manquerai pas de rouvrir si je recommence à réessayer. ;)

Cette page vous a été utile?
0 / 5 - 0 notes