Auto: Die Übernahme von Auto in ein bestehendes Projekt führt zu mehreren Versionen (wie kann man Fehler rückgängig machen?)

auto release --dry-run ist etwas hilfreicher als shipit :

~/Projects/ericclemmons/codelift 58-release
❯ yarn auto release --dry-run
yarn run v1.19.2
$ /Users/eric/Projects/ericclemmons/codelift/node_modules/.bin/auto release --dry-run
ℹ  info      Last used release: v0.5.0
⚠  warning   lerna notice cli v3.20.2
lerna success found 1 package

ℹ  info      Using release notes:
...
ℹ  info      Would have released (unless ran with "shipit"): v9.2.1

Nun, um herauszufinden, wie es zu v9.2.1 damit ich PRs entsprechend aktualisieren oder etwas anderes konfigurieren kann ...

Fortschritt ! Das Löschen des fehlerhaften Tags und das Entfernen der Versionshinweise scheinen die Verweise in GitHub-Aktionen zu beheben (obwohl local --dry-run immer noch v9.2.1 sieht):

1. git tag -d v9.2.1
2. git push --delete v9.2.1
3. (GitHub-Aktion erneut ausführen) https://github.com/ericclemmons/codelift/pull/58/checks?check_run_id=408281672

 - codelift: 0.5.0 => 0.5.1-canary.58.45c171c.0

Um herauszufinden, warum lokal (oder remote!) _jemals_ v9.2.1 aus v0.5.0 🤔

Das ist großartig, dass Sie auto ! Ich werde versuchen, das mit Ihnen zu debuggen.

@hipstersmoothie Mach dir keine Sorgen, eingräbst , ich https://github.com/ericclemmons/codelift/pull/58, bis ich eine Ziegelmauer treffe oder auf der anderen Seite herauskomme :D

Dies ist auf jeden Fall ein Bug auf unserer Seite. Das liegt daran, dass wir Ihre Beispiele finden, dasjenige mit der höchsten Version finden, das zufällig next , und das verwenden, um die neueste Version zu finden, die zufällig v9.2.0 , die dann ein erhält Patch angewendet, um v9.2.1 .

Das Entfernen von version aus den package.json meiner privaten Beispiele ergab eine andere Ausgabe:

yarn auto release --dry-run
yarn run v1.19.2
$ /Users/eric/Projects/ericclemmons/codelift/node_modules/.bin/auto release --dry-run
ℹ  info      Last used release: v0.5.0
ℹ  info      Using release notes:
...
ℹ  info      Would have released (unless ran with "shipit"): v0.5.0
✨  Done in 5.88s.

Beachten Sie, dass es überhaupt nicht erhöht wurde 🤔

Rückt näher! Ich werde das released Plugin entfernen und weiter tuckern:

$ auto shipit
✖  error     None of the plugins that you are using implement the `canary` command!

"canary" releases are versions that are used solely to test changes. They make sense on some platforms (ex: npm) but not all!

Hoppla, ich bin ein Dummkopf. Ich habe übersehen, dass plugins npm plugins überschreibt (ich ging davon aus, dass es als Standard bleiben würde, da es eine Abhängigkeit ist)

https://github.com/hipstersmoothie/auto-config-hipstersmoothie/blob/4dc2b725491fa196ac4723fae141f578e79c5382/package.json#L22 -L26

Beachten Sie, dass es überhaupt nicht inkrementiert wurde

Das ist einfach eine schlechte Nachricht. Eingehende PR, um klarer zu machen, was passiert

Erster Erfolg!!! 🎉

https://github.com/ericclemmons/codelift/pull/58/checks?check_run_id=408308903

Es ist cool, dies offen zu halten, aber wir können abbrechen, um Folgendes separat zu besprechen:

• Validierung vor Freigabe:

  • Aktualisierung der Dokumentation zur Hervorhebung von --dry-run als Teil des Abschnitts „Erste Schritte“. auto release --dry-run war für mich der zuverlässigste Weg, Zugangsdaten, Plugins usw. zu validieren. Ich freue mich, diese PR bei Interesse einzureichen!

• Das Verhalten von 0.5.0 zu 9.2.1 :

  • Dies kann auch ein Dokumentationsproblem sein: auto release --dry-run hätte die vorzeitige Veröffentlichung erspart, aber vielleicht ist die bessere Antwort, die Fehlerbehebung "Entferne version aus allen Paketen mit "private": true "?

• Wie funktioniert canary mit mehreren offenen PRs?

  • Für ein großes Projekt wie https://github.com/aws-amplify/amplify-js/ ist es enorm wichtig , dass jeder Commit in einer PR als Paket verfügbar ist! Aber mit mehreren PRs im Flug würde ich die Benutzer nicht anweisen, @canary zu installieren, sondern vielleicht @PR-123 . Dies könnte auch ein Dokumentations-/Sichtbarkeitsproblem sein, bei dem die GitHub-Aktion/Check mit einem Kommentar oder einer Angabe zur Installation der neuesten Version zurückkehren könnte (z. B. https://zeit.co/github#features).

"Entferne Version aus allen Paketen mit "private": true"

Fertig in #894

Bei Interesse reiche ich diese PR gerne ein!

Bitte pr. einreichen! Es ist wertvoll, verschiedene Standpunkte zu haben.

Ich würde die Benutzer auch nicht anweisen, das Canary-Tag zu installieren. Das Veröffentlichen unter diesem Tag ist mehr als das Veröffentlichen unter etwas anderem als dem neuesten. Es fungiert als Catch-All. Ein Tag wie PR-123 ist schön und Auto könnte das wahrscheinlich tun, wir müssten nur die Tags bereinigen, nachdem der Versand fertig ist. Dies wäre wahrscheinlich auch etwas benutzerfreundlicher.

Dies könnte auch ein Dokumentations-/Sichtbarkeitsproblem sein, bei dem die GitHub-Aktion/Prüfung mit einem Kommentar oder einer Angabe zur Installation der neuesten Version zurückkehren könnte

Sie haben es vielleicht nicht bemerkt, aber das passiert bereits. Überprüfen Sie Ihre PR

https://github.com/ericclemmons/codelift/pull/58#issue -367063354

Aber Achtung: GitHub-Aktionen geben keine Geheimnisse an Forks weiter! So erhalten gegabelte PRs keine Canary-Releases zur Veröffentlichung.

@ericclemmons sollten Sie yarn install --frozen-lockfile in CI-Umgebungen ausführen.

https://github.com/ericclemmons/codelift/runs/408316662

Auch [email protected] sollte ein schöneres --dry-run Erlebnis haben

Veröffentlichte PR mit Canary-Version: 0.5.1-canary.58.fea0a94.0

Oh, heiliger Mist! Es war so subtil, dass ich es nicht bemerkt habe!

Was halten Sie von einer PR, damit sie etwas visueller wird?

---

📦 Veröffentlichte PR mit Canary-Version: 0.5.1-canary.58.fea0a94.0

Ich bin immer auf der Suche nach mehr Emojis!

Zwei weitere Plugins, die dir gefallen könnten, sind

https://intuit.github.io/auto/plugins/all-contributors/README.html
https://intuit.github.io/auto/plugins/first-time-contributor/README.html

Danke für deine Aufmerksamkeit heute Abend @hipstersmoothie. Das hat bisher super geklappt!

Ich bin ehrlich gesagt überrascht, wie gut es funktioniert! Das ist kein einfaches Problem 😅😅

Zum Thema Monorepos suche ich Alternativen für https://github.com/aws-amplify/amplify-js/ :

• Sie haben Recht: Bei mehreren PRs im Flug wird canary widersprüchlich. Die derzeit beste Lösung wäre, Pakete mit einer GitHub-Aktion zu bereinigen, die PR-123 wenn PR-123 nicht geöffnet ist. (Ein Tag wie PR-123 zu haben, um immer auf das Neueste zu verweisen, ist IMO auch praktisch)

• Amplify verwendet independent Versionierung: Wie funktioniert das mit auto ?