Auto: La version Canary n'est pas ajoutée à certains PR dans GitHub Action

Créé le 9 juil. 2019  ·  21Commentaires  ·  Source: intuit/auto

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.

bug released

Tous les 21 commentaires

@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 :

  1. pousser le code
  2. prendre beaucoup de temps à écrire un message pr
  3. la version canary publie avant que vous ne soumettiez les relations publiques et essaie de publier des commentaires sur les relations publiques qui n'ont pas encore été ouvertes
  4. pas de version canari publiée sur PR

@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 :

  1. pousser le code vers une nouvelle branche
  2. ci exécute la construction
  3. Parfois, après la construction, vous ouvrez PR
  4. version jamais posté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 :

  1. le numéro PR détecté https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L653
  2. Le corps des relations publiques enregistrera également tout ce qu'il fait https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L555

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:

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