Auto: Canary-Version wird einigen PRs in der GitHub-Aktion nicht hinzugefügt

@zephraph Ist dieses Problem in letzter Zeit

Ich habe nicht. Wird schließen.

Das hätte sehr gut so passieren können:

1. Push-Code
2. dauert lange, eine pr-Nachricht zu schreiben
3. Canary-Version wird veröffentlicht, bevor Sie PR einreichen und versucht, einen Kommentar zu PR zu posten, der noch nicht geöffnet wurde
4. keine kanarische Version auf PR . gepostet

@zephraph Dies könnte eine Gelegenheit für Autobot sein, die Canary-Version hinzuzufügen.

Ich sehe dies auch bei 8.0.0 , wenn die Protokolle angezeigt werden:

✔  success   Published canary version: <details><summary>Canary Versions</summary>- `[email protected]`
- `[email protected]`</details>

Aber der PR-Kommentar wird nicht aktualisiert. Ich verwende das standardmäßige auto init Setup mit den Plugins npm und released .

War die PR zum Zeitpunkt der Veröffentlichung des Kanarienvogels geöffnet?

Wenn Sie Folgendes tun, wird die Canary-Version nicht gepostet:

1. Code in neue Filiale verschieben
2. ci führt build aus
3. Manchmal öffnet man nach dem Build PR
4. Version nie zurück gepostet

Build endet, nachdem ich die PR erstellt habe.

Wenn es fertig war, bevor der PR erstellt wurde, wird es immer noch nicht aktualisiert, wenn ich neue Commits pushe. Muss es beim ersten Mal funktionieren, damit zusätzliche Commits auch die PR-Beschreibung aktualisieren?

Danke nochmal für die Unterstützung

Muss es beim ersten Mal funktionieren, damit zusätzliche Commits auch die PR-Beschreibung aktualisieren?

Für nachfolgende Builds sollte es keine Rolle spielen. Kann ich mir das Repo mal anschauen?

Möglicherweise wird Ihre PR auf Ihrer Build-Plattform nicht erkannt. Ich werde hier ein paar Logs hinzufügen

https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L692

Wenn man es genauer betrachtet, sollte fast alles bereits in den Protokollen enthalten sein. Kannst du veryVerbose einschalten und ein Log posten?

Wir sollten sehen können:

1. die erkannte PR-Nummer https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L653
2. PR-Körper protokolliert auch alles, was es tut https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L555

PR wird also tatsächlich nicht für Canary-Release gefunden (obwohl es die PR-Nummer in der ersten Protokollzeile erhält):

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

Zu Ihrer Information Ich verwende lerna im unabhängigen Modus. Das Repo ist intern, aber es ist ein POC, also werde ich es wahrscheinlich in ein öffentliches verschieben, damit ich es Ihnen zeigen kann, es ist einfacher, auf diese Weise zu debuggen 🙂 Montag tho

@hipstersmoothie Hier ist das Test-Repo: https://github.com/glambert/auto-lerna-independent-poc

Ich schaue mir das morgen an. Danke für das Test-Repo! Es wird sehr helfen

Am So., 15. Dez. 2019 um 18:32 Uhr Guillaume Lambert [email protected]
schrieb:

Hier ist das Test-Repo:
https://github.com/glambert/auto-lerna-independent-poc

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/intuit/auto/issues/481?email_source=notifications&email_token=AAJDEBCGLTAHIMJAI3JWYC3QY3SEHA5CNFSM4H7BEXSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTPWS6
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAJDEBEP47ROT67TB5KOJUTQY3SEHANCNFSM4H7BEXSA
.

Ah, dies kann mit einigen Vorbehalten zusammenhängen, die ich bei GitHub-Aktionen gefunden habe.

Diese Bibliothek erkennt den Branch/PR nicht richtig https://github.com/pvdlg/env-ci/issues/96

Die Getting commits for PR #4 stammen von uns, die den Commit-SHA mit einem PR abgleichen, leider nicht die Umgebungsinformationen.

Ich werde ein bisschen damit herumspielen, um zu sehen, ob ich env-ci dazu bringen kann, sich so zu verhalten, wie ich es möchte

Es sieht so aus, als ob das push Ereignis nicht das ist, was wir wollen?

https://mobile.twitter.com/ethomson/status/1176421835157704704

Ich habe eine eingehende PR, die die PR findet, mit der der Head-Commit für Canary-Versionen verknüpft ist. Dies sollte bei der Suche nach der PR helfen, die Sie kommentieren möchten

Ahhh richtig, also hast du sowohl push als auch pull_request als Trigger?

Ich probiere es mal mit der Canary-Version des PR und lasse dich wissen, ob es funktioniert 👍 letztendlich werde ich Canary-Releases mit lerna Independant-Modus nicht verwenden, da es Canary für alle Pakete erstellen würde, auch für unveränderte. Aber wenigstens weiß ich, dass es funktioniert 😉

Ahhh richtig, also hast du sowohl push als auch pull_request als Trigger?

Ich habe GitHub-Aktionen noch nicht so oft verwendet, also IDK, was der bisher beste Workflow ist (hoffentlich können Sie uns helfen, ihn zu finden 😃). Für mich ist es ein bisschen zu viel Aufwand, mehrere Aktionen einzurichten. Wenn mein Kanarienvogel funktioniert, sollte dies das Problem größtenteils lindern.

Am Ende verwende ich möglicherweise keine Canary-Versionen mit dem unabhängigen Modus von lerna, da dies für alle Pakete, auch für die unveränderten, Canary erstellen würde

Da jetzt mehrere Benutzer beantragt haben, dass ich die Veröffentlichung von Kanarienvögeln nicht erzwinge, bin ich offen dafür. Aber meiner Erfahrung nach habe ich festgestellt, dass Sie sie für Randfälle erzwingen möchten.

Zum Beispiel, wenn Sie Ihre Babel-Konfiguration ändern und die Änderungen an einer Canary-Version testen möchten. Ohne erzwungene Veröffentlichung wird lerna nicht alles veröffentlichen, wenn Sie nur eine globale Konfigurationsdatei ändern, da sich keine Pakete tatsächlich geändert haben.

Aus welchen Gründen möchten Sie nicht, dass alles auf einem Kanarienvogel aktualisiert wird? Ich bin kein independant Benutzer, daher kann es sein, dass mir etwas fehlt.

Aus welchen Gründen möchten Sie nicht, dass alles auf einem Kanarienvogel aktualisiert wird? Ich bin kein unabhängiger Benutzer, daher kann es sein, dass etwas fehlt.

Wir haben ein Repository von mehr als 20 Bibliotheken (und wachsend), so dass es sehr laut werden wird, für alle diese Veröffentlichungen bei jedem PR zu veröffentlichen. Was ich dachte, ist stattdessen, ob Sie vielleicht die Verzweigungsstrategie next . Das Gute an der Verwendung von canary ist, dass Sie einzelne Commits testen können. Gibt es eine Möglichkeit, canary für bestimmte Pakete im independent Modus "manuell" auszulösen? Beispiel: Führen Sie lerna changed und erstellen Sie Canary-Releases nur für die Pakete, die sich geändert haben. Hier laut nachdenken 😉

derzeit nicht.

https://github.com/intuit/auto/blob/master/plugins/npm/src/index.ts#L562

Ich bin offen für das Hinzufügen eines Flags / einer Konfiguration wie --no-force-publish-canary . Ich möchte die Standardeinstellung beibehalten.

Ich bin offen für das Hinzufügen eines Flags / einer Konfiguration wie --no-force-publish-canary. Ich möchte die Standardeinstellung beibehalten

Zugegeben, in den meisten Fällen ist dies das, was Sie wollen.

:rocket: Ausgabe wurde in v9.1.0 veröffentlicht :rocket: