Auto: npm-Plugin stößt die Version in package.json nicht an

Dies ist beabsichtigt. Wenn die Version festgeschrieben ist, kann es beim Zusammenführen in den Master zu Zusammenführungskonflikten kommen. Es gibt jedoch ein Git-Tag, das erstellt wird

Dieses Problem betrifft auch mich.

Dies ist beabsichtigt. Wenn die Version festgeschrieben ist, kann es beim Zusammenführen in den Master zu Zusammenführungskonflikten kommen. Es gibt jedoch ein Git-Tag, das erstellt wird

Was ist der empfohlene Ansatz, um sicherzustellen, dass package.json Versionen mit CI-Bereitstellungen mit auto shipit synchron bleiben?

Ich bin mir nicht sicher, ob ich den Anwendungsfall @smithki ganz verstehe. Der Anwendungsfall von

Entschuldigung, vielleicht habe ich ein Missverständnis. Aus dem Wortlaut der Ausgabe vermute ich, dass next Branches keine aktualisierten package.json Versionen erhalten, aber main Branches (immer noch auto lernen) . Mein Anwendungsfall ist der gleiche wie in der ursprünglichen Ausgabe, aber um genau zu sein:

Ich muss die package.json Version zur _build_-Zeit für eine NPM-Bibliothek lesen, damit die aktuelle package.json Version als Umgebungsvariable eingefügt werden kann. Das bedeutet, dass ich die package.json Dateien versionieren muss, bevor der Build ausgeführt wird. Das einfache Importieren von package.json funktioniert nicht gut mit meinem aktuellen TypeScript-Setup, das von rootDirs in tsconfig.json abhängt (und package.json ist nicht in rootDirs , also ein Compilerfehler, also die Notwendigkeit einer Umgebungsvariablen).

Könnten Sie einfach tun, was auto tut? https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306 -L310

Ich werde sehen, ob ich es umgehen kann, nicht meine Absicht, das ursprüngliche Thema dieses Problems zu entgleisen.

Könnten Sie einfach tun, was Auto tut? https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306 -L310

Leider nicht, da der Code clientseitig ausgeführt werden soll (ich werde ein neues Problem eröffnen, wenn ich keine Problemumgehung finde).

Ah, noch eine Stimme für mich, das Trockenlaufverhalten eher früher als später zu beheben. Werde am nächsten Wochenende mal schauen ob das alles repariert wird. Danke für das Feedback und die Verwendung von auto !

@hipstersmoothie Danke für die schnelle Antwort :) Ihr überrascht mich immer wieder

Ich habe für den Moment einen ziemlich soliden Workaround gefunden, auto shipit --dry-run --plugins git-tag . Das macht eigentlich sowieso sehr viel Sinn, um auf diesem Weg nach Vorabversionen nach der nächsten Version zu suchen.
Vielen Dank, dass Sie so bald einen Versuch mit Probelauf-Verbesserungen gemacht haben. Wenn Sie einen Kanarienvogel-Build ausprobieren möchten, lassen Sie es mich wissen. Ich helfe gerne.

Auf jeden Fall vielen Dank für auto ! Es hat mein Leben so viel einfacher gemacht

@thuringia @smithki Könnten Sie testen, ob v10 Ihre Probleme löst?

@hipstersmoothie Das funktioniert in v10 gut
Es ist jedoch merklich langsamer, oder besser gesagt, es dauert so lange, wie shipit ohne --dry-run .

Danke, dass du das so schnell rausbekommst!

Ich bin mir nicht sicher, ob das ein Fehler ist oder nicht:
Als ich die Pakete mit yarn add -D auto@next aktualisierte, waren die Änderungen an package.json und yarn.lock weg, nachdem auto shipit --dry-run . v10 war noch in meinem node_modules also sieht es so aus, als ob das Arbeitsverzeichnis zurückgesetzt wurde.

Es ist jedoch merklich langsamer, oder besser gesagt, es dauert so lange, wie shipit ohne --dry-run ausgeführt wird.

Ich werde sehen, ob ich das verbessern kann. Aber da wir das Plugin jetzt aufrufen, macht es viel mehr Arbeit, die echten nächsten Versionen zu drucken.

die Änderungen an package.json und Garn.lock waren nach dem Ausführen von auto shipit --dry-run . verschwunden

Ach das ist ein Bug. Für den Probelauf habe ich den Clean-Check übersprungen, aber den Git-Reset nicht übersprungen

@thuringia Welche Art von Projekt veröffentlichen Sie?

@hipstersmoothie Mir geht es völlig gut,
Jede Leistungssteigerung ist jedoch immer willkommen.

In diesem Fall ist es ein gemischtes Projekt, das hauptsächlich aus einer Java-Anwendung mit einigen Lambdas besteht. Um eine Freigabe zu erstellen, muss ich:

• Führen Sie gradle aus, um das Glas mit der Versionsnummer zu erstellen
• Verpacken Sie dieses JAR in ein Docker-Image, markieren Sie es und veröffentlichen Sie es
• Bereitstellung von Lambdas mithilfe eines serverlosen Frameworks, das die Versionsnummer zum Tagging und zum Konfigurieren der Container verwendet

Nicht wirklich ein Standardanwendungsfall für auto 😂
Normalerweise verwende ich es für Node- oder React-Projekte mit optimierten Setups, aber ich musste nie eine Versionsnummer erhalten, bevor ich die Version tatsächlich veröffentliche, wie ich es für dieses spezielle Projekt brauche

:rocket: Ausgabe wurde in v10.0.0 :rocket: