Décrivez le bogue
J'ai remarqué que sur les PR que je crée, même si les versions Canary sont publiées, le corps du PR n'est pas mis à jour pour avoir le numéro de version.
Reproduire
Voir l'un de mes PR pour un repo.
Comportement prévisible
J'ai créé un dépôt, une version Canary a été déployée, mais la modification des relations publiques Canary n'a pas été effectuée au bas du dépôt.
Contexte supplémentaire
Je suppose qu'il s'agit en fait d'un problème d'autorisation.
@zephraph Avez-vous vu ce problème apparaître récemment ?
Je n'ai pas. Fera fermer.
Cela aurait très bien pu se passer comme ceci :
@zephraph Cela pourrait être une opportunité pour autobot d'ajouter la version canary.
Je vois cela aussi sur 8.0.0
, l'activation des journaux affiche :
✔ success Published canary version: <details><summary>Canary Versions</summary>- `[email protected]`
- `[email protected]`</details>
Mais le commentaire PR n'est pas mis à jour. J'utilise la configuration par défaut de auto init
avec les plugins npm
et released
.
Le PR était-il ouvert au moment de la publication du canari ?
Si vous procédez comme suit, la version Canary ne sera pas publiée :
La construction se termine après que j'ai créé le PR.
S'il s'est terminé avant la création du PR, lorsque je pousse de nouveaux commits, il ne se met toujours pas à jour. Doit-il fonctionner la première fois pour que les commits supplémentaires mettent également à jour la description du PR ?
Merci encore pour le soutien
Doit-il fonctionner la première fois pour que les commits supplémentaires mettent également à jour la description du PR ?
Cela ne devrait pas avoir d'importance pour les versions ultérieures. Est-ce que je peux vérifier le repo?
Peut-être que votre PR n'est pas détecté sur votre plate-forme de construction. Je vais ajouter quelques logs ici
https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L692
En y regardant de plus près, tout devrait déjà être dans les journaux. Pouvez-vous activer veryVerbose et publier un journal ?
On devrait pouvoir voir :
Donc PR n'est en effet pas trouvé pour la version Canary (bien qu'il obtienne le numéro PR dans la première ligne de journal):
info Getting commits for PR #4
302
ℹ info {
303
currentBranch: 'package-2-update',
304
isBaseBrach: false,
305
isPR: false,
306
shouldGraduate: true,
307
isPrereleaseBranch: false,
308
publishPrerelease: false
309
}
310
ℹ info Canary info found: { pr: undefined, build: undefined }
311
ℹ info Getting commits from HEAD^ to HEAD
Pour info, j'utilise lerna en mode indépendant. Le repo est interne mais c'est un POC, donc je vais probablement le déplacer vers un public afin que je puisse vous montrer, ce sera plus facile à déboguer de cette façon 🙂 Lundi tho 😉
@hipstersmoothie Voici le repo de test : https://github.com/glambert/auto-lerna-independent-poc
Je regarderai ça demain. Merci pour le repo test! ça va beaucoup aider
Le dimanche 15 décembre 2019 à 18h32 Guillaume Lambert [email protected]
a écrit:
Voici le dépôt de test :
https://github.com/glambert/auto-lerna-independent-poc-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
Https://github.com/intuit/auto/issues/481?email_source=notifications&email_token=AAJDEBCGLTAHIMJAI3JWYC3QY3SEHA5CNFSM4H7BEXSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW8Z06Z06KTDN5WWGZQ6Z
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJDEBEP47ROT67TB5KOJUTQY3SEHANCNFSM4H7BEXSA
.
Ah, cela peut être lié à certaines mises en garde que j'ai trouvées avec les actions GitHub.
Cette bibliothèque ne détecte pas correctement la branche/PR https://github.com/pvdlg/env-ci/issues/96
Le Getting commits for PR #4
vient de nous en faisant correspondre le commit SHA à un PR, pas les informations d'environnement malheureusement.
Je vais jouer un peu avec pour voir si je peux faire en sorte que env-ci se comporte comme je le veux
Il semble que l'événement push
n'est peut-être pas ce que nous voulons ?
https://mobile.twitter.com/ethomson/status/1176421835157704704
J'ai un PR entrant qui trouvera le PR auquel le commit principal est associé pour les versions Canary. Cela devrait aider à trouver le PR pour commenter
Ahhh d'accord, donc vous auriez à la fois push et pull_request comme déclencheurs ?
Je vais essayer avec la version canary du PR et vous ferai savoir si cela fonctionne 👍 à la fin, je pourrais ne pas utiliser les versions canari avec le mode indépendant de lerna car cela créerait canary pour tous les packages, même ceux qui ne sont pas modifiés. Mais au moins je saurai que ça marche
Ahhh d'accord, donc vous auriez à la fois push et pull_request comme déclencheurs ?
Je n'ai pas tellement utilisé les actions GitHub, donc IDK quel est le meilleur workflow à ce jour (j'espère que vous pourrez nous aider à le trouver 😃). Pour moi, la configuration de plusieurs actions est un peu trop lourde. Si mon canari fonctionne, cela devrait résoudre le problème en grande partie.
à la fin, je pourrais ne pas utiliser les versions canary avec le mode indépendant de lerna car cela créerait canary pour tous les packages, même les packages inchangés
Étant donné que plusieurs utilisateurs ont maintenant demandé que je ne force pas la publication des canaris, je suis ouvert à cela. Mais d'après mon expérience, j'ai découvert que vous vouliez forcer leur publication pour les cas extrêmes.
Par exemple, si vous modifiez votre configuration babel et que vous souhaitez tester les modifications sur une version Canary. Sans la publication forcée, lerna
ne publiera rien si vous modifiez simplement un fichier de configuration global, car aucun package n'a réellement changé.
Quelles sont les raisons pour lesquelles vous ne voulez pas que tout soit mis à jour dans un canari ? Je ne suis pas un utilisateur de independant
donc il y a peut-être quelque chose qui me manque.
Quelles sont les raisons pour lesquelles vous ne voulez pas que tout soit mis à jour dans un canari ? Je ne suis pas un utilisateur indépendant donc il y a peut-être quelque chose qui me manque.
Nous avons un référentiel de plus de 20 bibliothèques (et en pleine croissance), donc faire des versions Canary pour toutes celles-ci sur chaque PR deviendra très bruyant. Ce que je pensais, c'est plutôt d'utiliser la stratégie de branche next
. L'avantage d'utiliser canary
est que vous pouvez tester des commits individuels. Existe-t-il un moyen de déclencher canary
« manuellement » pour des packages spécifiques en mode independent
? Par exemple : exécutez lerna changed
et créez des versions Canary uniquement pour les packages qui ont changé. Penser à voix haute ici 😉
pas actuellement.
https://github.com/intuit/auto/blob/master/plugins/npm/src/index.ts#L562
Je suis prêt à ajouter un drapeau/config comme --no-force-publish-canary
. Je veux garder la valeur par défaut telle qu'elle est.
Je suis ouvert à l'ajout d'un indicateur/configuration comme --no-force-publish-canary. Je veux garder la valeur par défaut telle qu'elle est
D'accord, pour la plupart des cas, c'est ce que vous voudriez.
:rocket: Le problème a été publié dans la version 9.1.0 :rocket: