Auto: Entfernen Sie die Anforderung für das Maven-Release-Plugin

Ich stimme vollkommen zu!

Die meisten Ihrer Punkte mit Informationen, die ich aus der pom.xml bekomme, hängen wahrscheinlich mit meinem Missverständnis dieser Felder zusammen. Änderungen sind hier mehr als willkommen.

Ich bin für alle bahnbrechenden Veränderungen, die wir machen müssen. Wir können wahrscheinlich einige der kleineren Breaking Changes ausführen, die in #1156 beschrieben sind

Es sieht so aus, als ob meine beiden Punkte zu <scm/> und <developers/> falsch sind. Das npm Plugin zieht diese aus dem package.json . Bedeutet dies, dass sie sich im pom.xml _sollten_ ?

Wenn dies die pom Äquivalente der npm-Felder repository und author sind, dann ja.

Der Autor wird über die eingestellt Abschnitt der pom.xml, was bedeutet, dass die Person, die den Commit durchführt, NICHT dieselbe Person sein darf wie der ausgewählte Autor. Es gibt keinen Versuch, den Git-Commit-Autor mit dem auszurichten Information.

Dies gilt auch für das npm-Plugin. Locally auto überschreibt Ihre git Konfiguration nicht, aber in einer CI-Umgebung muss es möglicherweise author zum Festschreiben setzen.

Die Besitzer- und Repo-Informationen werden über die Abschnitt, der sich vom tatsächlichen Repository und Besitzer des aktuellen Klons unterscheiden kann.

Wäre dies anders? In npm world zeigt das Feld repository normalerweise auf den Code für das Paket. In der Praxis wird auto normalerweise nicht auf einem fork und wenn dies der Fall wäre, würde ich hoffen, dass sie das Feld repository auf ihre Gabel aktualisieren

Okay, das macht Sinn - also ist das richtige Verhalten, nach diesen Dingen (aktuell) zu suchen, und wenn sie NICHT in pom.xml , kehren Sie zurück und nehmen Sie an, dass sie in .autorc (neues Verhalten).

Derzeit führt das Plugin einen Fehler aus, wenn es die Abschnitte <scm/> und <developers/> in den pom.xml .

Ah ja das ist definitiv ein Bug. Es sollte keine Fehler auslösen https://github.com/intuit/auto/blob/master/plugins/npm/src/index.ts#L504

Gibt es eine Möglichkeit, die Versionsnummer von auto maschinenlesbar zu erhalten? Ich war überrascht, dass der Befehl auto version den TYPE des Versionsbumps erzeugt und nicht die Nummer.

Sie können --quiet und es wird nur die vom Befehl erzeugte Version gedruckt. oder koppeln Sie es mit --dry-run und Sie können sehen, welche Version als nächstes veröffentlicht wird.

Ich wäre vielleicht bereit, ein Flag hinzuzufügen, damit version die aktuelle Version ausspuckt. Das wird in Multi-Paket-Szenarien nur seltsam

Ich kann sehen, dass. Es ist wahrscheinlich besser, dies dem Anrufer zu überlassen, um herauszufinden, nach welcher Version er sucht.

Ihr Punkt zu Multi-Paket-Szenarien ist hier relevant - das Maven-Release-Plugin unterstützt diese Art von Szenario sofort. Das lässt mich fragen, ob ich diese Arbeit reproduzieren möchte. Ich stecke in einer Sackgasse - einerseits ist mein Argument, das Maven-Release-Plugin NICHT zu verwenden, gültig, während andererseits Dinge wie die Versionsverwaltung von Submodulen ein nicht trivialer Anwendungsfall sind, der sollte angesprochen werden und wird durch das maven-release-plugin abgedeckt.

Ich habe zwei Methoden gefunden, um das Maven-Release-Plugin zu verwenden, um zu verhindern, dass das Maven-Plugin das Repository während release:prepare ändert, und werde sie heute später testen.

@hipstersmoothie Ich habe eine Frage zum Verhalten von getAuthor , getRepo usw. - RE: der Kommentar zu https://github.com/intuit/auto/issues/1260#issuecomment - 634280655, ich schaue mir die Tests an und sie scheinen dem zu widersprechen.

Beispiel:
https://github.com/intuit/auto/blob/47d3b54ef1a7af990fe0ca898e747dd833fde3b1/plugins/maven/__tests__/maven.test.ts#L95

Wenn ich also ein undefined AuthorInformation kein Fehler ausgegeben.

Irgendwelche Vorschläge, was ich falsch machen könnte oder ob ich throw in mein Hook-Handling einführen sollte?

Das ist definitiv falsch, wenn man bedenkt, wie alle anderen Plugins funktionieren. Undefiniert zurückzugeben ist der richtige Weg. Auf diese Weise kann core Bedarf auf den lokal konfigurierten git Benutzer zurückgreifen

Gotcha - das habe ich mir gedacht, also habe ich die Tests modifiziert, um sicherzustellen, dass fehlgeschlagene Hooks undefined .

Es sieht so aus, als ob sowohl das Gradle- als auch das Cocoapods-Plugin Fehler ausgeben, wenn sie keine Version finden können. Ich habe einen Fehler für das Gradle-Plugin erstellt - möchten Sie einen weiteren für Kakaofrüchte?

Lassen Sie einfach ein nicht zu dem Thema. Danke für den Fang!

Ich kämpfe mit einer guten Methode zum Testen der Initialisierung von Werten während hooks.beforeRun . Insbesondere habe ich den folgenden Code, der beim Debuggen die Autoreninformationen während des hooks.beforeRun Tippens erfolgreich extrahiert, den Test jedoch nicht besteht:

    test("should get author from pom.xml", async () => {
      mockRead(`
        <project
          xmlns="http://maven.apache.org/POM/4.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
          <developers>
            <developer>
              <name>Andrew Lisowski</name>
              <email>[email protected]</email>
            </developer>
          </developers>
        </project>
      `);

      await hooks.beforeRun.promise({} as any);

      expect(await hooks.getAuthor.promise()).toStrictEqual(
        expect.objectContaining({
          email: "[email protected]",
          name: "Andrew Lisowski",
        })
      );
    });

Der Test erreicht den Hook getAuthor , BEVOR der Hook beforeRun wird. Ich habe mir anderen Code angesehen, der dies testet (gradle, s3), und habe kein Glück.

Im Grunde brauche ich eine Möglichkeit, den beforeRun Hook deterministisch auszuführen, und kann nicht herausfinden, wie das geht.

einen Ast schieben und ich kann es mir anschauen

@hipstersmoothie hier ist der Zweig: https://github.com/terradatum/auto/tree/remove-maven-release-plugin-requirement

Ich habe den Code auskommentiert, der meine Änderungen in das zentrale Repository verschieben würde, damit ich den Code in einem echten Projekt testen kann, ohne den Remote-Verlauf zu verschmutzen.

Jede Hilfe, die Sie mir dabei geben können, ist sehr willkommen - ich würde gerne die Tests verwenden, um zu überprüfen, wie gut ich die pom.xml-Dateien modifizieren kann, anstatt auf die alte Methode "Code ausführen" zurückzugreifen echte Dateien, überprüfen Sie die echten Dateien, führen Sie git reset --hard HEAD~1 , um die Änderungen zu entfernen, spülen und wiederholen Sie den Vorgang."

Außerdem musste ich einige Änderungen am lokalen package.json vornehmen, die mit dem Root- package.json kompatibel waren, um die Scherztests in IntelliJ auszuführen - gibt es eine Anleitung, die Sie mir dazu geben können, oder sollte es "einfach funktionieren"?

Insbesondere, wenn Sie sich im Maven-Plugin-Verzeichnis befinden und npm test ausführen, werden ALLE Tests ausgeführt, weil "test": "jest --maxWorkers=2 --config ../../package.json" .

Und wenn ich versuche, den IntelliJ Test Runner aus dem Editor zu verwenden, erhalte ich:

  ● Test suite failed to run

    SyntaxError: /home/rbellamy/Development/Terradatum/auto/plugins/maven/__tests__/maven.test.ts: Unexpected token, expected "," (15:24)

      13 | }));
      14 | 
    > 15 | const mockRead = (result: string) =>
         |                         ^
      16 |   jest
      17 |     .spyOn(fs, "readFile")
      18 |     // @ts-ignore

      at Parser._raise (../../node_modules/@babel/parser/src/parser/location.js:241:45)
      at Parser._raise [as raiseWithData] (../../node_modules/@babel/parser/src/parser/location.js:236:17)
      at Parser.raiseWithData [as raise] (../../node_modules/@babel/parser/src/parser/location.js:220:17)
      at Parser.raise [as unexpected] (../../node_modules/@babel/parser/src/parser/util.js:149:16)
      at Parser.unexpected [as expect] (../../node_modules/@babel/parser/src/parser/util.js:129:28)
      at Parser.expect [as parseParenAndDistinguishExpression] (../../node_modules/@babel/parser/src/parser/expression.js:1293:14)
      at Parser.parseParenAndDistinguishExpression [as parseExprAtom] (../../node_modules/@babel/parser/src/parser/expression.js:1029:21)
      at Parser.parseExprAtom [as parseExprSubscripts] (../../node_modules/@babel/parser/src/parser/expression.js:539:23)
      at Parser.parseExprSubscripts [as parseMaybeUnary] (../../node_modules/@babel/parser/src/parser/expression.js:519:21)
      at Parser.parseMaybeUnary [as parseExprOps] (../../node_modules/@babel/parser/src/parser/expression.js:311:23)

Ich kann mein Problem mit IntelliJ lösen, indem ich eine jest.config.ts Datei hinzufüge:

module.exports = {
  clearMocks: true,
  moduleFileExtensions: ['js', 'ts'],
  testEnvironment: 'node',
  testMatch: ['**/*.test.ts'],
  testRunner: 'jest-circus/runner',
  transform: {
    '^.+\\.ts$': 'ts-jest'
  },
  verbose: true
}

Und dann fügen Sie jest-circus entweder zu den Root- oder Maven- package.json Dateien hinzu.

Habe gerade bemerkt, dass xml2js die Aufgabe nicht erledigen wird, da es alle XML-Kommentare während der XML => JSON => XML-Übersetzungen stillschweigend ENTFERNT. Ich habe versucht, es zum Laufen zu bringen, und es ist wie Zähne ziehen. Es gibt keine Garantie dafür, dass das XML beim Durchlaufen der xml2js Transformationen dem Original ähnelt, und das ist ein Deal-Breaker.

Um Tests für nur ein Plugin auszuführen, führe ich es vom Stamm aus.

yarn test plugins/maven

Dies wirft dann die Frage auf, ob Sie alle Änderungen, die Sie vornehmen würden, oder die Artefakte, die Sie erstellen würden, problemlos anzeigen können, ohne tatsächlich einige Änderungen vorzunehmen.

Das scheint ein ziemlich großer Dealbreaker zu sein. Gibt es in Java-Umgebungen eine Standard-CLI, die das Bearbeiten dieser Datei ermöglicht?

Für Plugins, die keinen Parser für die Konfigurationsdatei haben (zB Ruby) verwendet auto hauptsächlich Regex, um die Datei zu aktualisieren.

Hatten Sie Gelegenheit, sich das Problem beforeRun anzusehen? Ich habe einen Workaround, aber es fühlt sich wirklich hackig an...

Ich mag die Idee, Regex mit XML zu verwenden, wirklich nicht - es ist fehleranfällig und spröde. Es scheint jedoch auch lächerlich komplex zu versuchen, ein DOMParser oder XMLSerializer nur um die Version zu ändern, weshalb ich in erster Linie versucht habe, mit xml2js zu arbeiten.

Schau dir das jetzt an!

https://github.com/terradatum/auto/blob/remove-maven-release-plugin-requirement/plugins/maven/src/index.ts#L127

Das Problem ist, dass Sie einen "synchronen" Tap ausführen und darin asynchrone Arbeit ausführen

Ändere das

auto.hooks.beforeRun.tap(this.name, async () => {

dazu

auto.hooks.beforeRun.tapPromise(this.name, async () => {

Ah, der Hook vor dem Ausführen ist gerade synchronisiert, das ist das eigentliche Problem. Es würde nichts ändern, wenn das AsyncSeriesHook statt SyncHook . Ich kann einen Commit an deinen Branch senden, wenn unklar ist, was ich sage

Bitte tun Sie... lassen Sie mich Sie zu einem Mitwirkenden machen.

Fortfahren!

Einfach geschoben. Habe die Tests durchgeführt und nur zwei sind jetzt fehlgeschlagen. Der beforeRun-Hook funktioniert wie erwartet.

@hipstersmoothie Ich sehe das Commit zum Terradatum / Auto Repo nicht?

jetzt habe ich tatsächlich geschoben

Wird dies zu einer Breaking Change für jedes Plugin führen, das derzeit den synchronen Tap verwendet?

Nö. Sync Taps sollte genauso funktionieren. Dies fügt nur die Möglichkeit hinzu, ein Versprechen zu tippen

Ich habe diese Arbeit erfolgreich mit sprödem / fehleranfälligem Regex gemacht. Meine Sorge ist, dass das <version/> Element ÜBERALL in einer pom.xml -Datei verwendet wird - für die Artefaktversion UND für die Abhängigkeiten und Plugins. Mit anderen Worten, es ist sehr wahrscheinlich, dass die Regex versehentlich eine Version ändert, die sie nicht sollte.

Beim Versuch, mit XML DOM (über xmldom, xmldom-ts, xml2js, xml2json usw.) zu arbeiten, stecke ich in einem Sumpf epischen Ausmaßes fest. Ich betrachte mich keineswegs als Typoskript- oder Javascript-Experte, also falle ich vielleicht genau da hin.

Zwei Dinge treten mir in den Arsch:

1. Ich kann nicht herausfinden, wie man IntelliJ dazu bringt, die Maven-Tests (und NUR die Maven-Tests) im Debug-Modus auszuführen. Manchmal funktioniert es, manchmal nicht.
2. Laden Sie die pom.xml in ein Document und verwenden Sie dann xpath, um die Knoten "/project/version" und "/project/parent/version" auszuwählen.

Zwischen diesen beiden Problemen habe ich wahrscheinlich insgesamt 12 bis 16 Stunden verbracht und bin wirklich frustriert. Ich hatte Nr. 1 bis heute Morgen arbeiten müssen, und ich würde denken, dass Nr. 2 relativ einfach sein sollte, aber es scheint mich auf Schritt und Tritt zu bekämpfen.

Ich bin geneigt, das maven-release-plugin aus dem lächerlich einfachen Grund wieder zu verwenden, da es die Aktualisierung der pom.xml-Dateien für mich übernimmt.

Ich kann nicht herausfinden, wie man IntelliJ dazu bringt, die Maven-Tests (und NUR die Maven-Tests) im Debug-Modus auszuführen. Manchmal funktioniert es, manchmal nicht.

Es tut mir leid, dass ich hier keine weitere Hilfe bin. Ich verwende VSCode und debugge die Tests selten. Kannst du mit yarn test plugins/maven von root aus starten?

Laden Sie die pom.xml in ein Dokument und verwenden Sie dann xpath, um die Knoten "/project/version" und "/project/parent/version" auszuwählen.

Dies scheint eine gute Methode zu sein. Wenn das funktionieren könnte, scheint das gut zu sein.

Ich bin geneigt, das maven-release-plugin aus dem lächerlich einfachen Grund wieder zu verwenden, da es die Aktualisierung der pom.xml-Dateien für mich übernimmt.

Gibt es für Maven nur Plugin-basierte Dinge wie https://stackoverflow.com/questions/5726291/updating-version-numbers-of-modules-in-a-multi-module-maven-project ? ein Low-Level-mvn-basiertes Ding wäre perfekt.

Übrigens, danke, dass du so viel Zeit damit verbracht hast!

Danke für das Feedback und die Unterstützung. Entschuldigung für den rant (ish) vorherigen Kommentar.

Toller Punkt über das Versionen-Maven-Plugin - ich habe noch nie damit gearbeitet und hatte keine Ahnung, dass es existiert. Das wird es mir sicherlich leichter machen... Es ist ein perfekter Kompromiss zwischen dem Maven-Release-Plugin und dem Versuch, die pom.xml-Dateien über das Auto-Plugin zu verwalten.

Ich kann yarn test plugins/maven zum Arbeiten bringen. Ich bin auch ein großer Fan davon, den Debugger zu verwenden, um Dinge zu inspizieren, anstatt das traditionellere console.log , also verursache ich mir wahrscheinlich mehr Sodbrennen, als ich brauche ...

Nach einer langen und mühsamen Reise habe ich fast eine Lösung, die ich für eine vollständige Lösung halte, die entweder die pom.xml Dateien direkt modifiziert oder die versions-maven-plugin zum Setzen von Versionen verwendet.

Es gibt einige Vorbehalte. Der zum Modifizieren von pom.xml verwendete Code arbeitet mit einem DOM, was folgende Konsequenzen hat:

1. Es gibt einen Fehler in der Verarbeitung von tsconfig.json , der erfordert, dass die "dom" vor "es2017" in "compilerOptions" :

funktioniert:

"compilerOptions": [ "dom", "es2017" ]

funktioniert nicht:

"compilerOptions": [ "es2017", "dom" ]

Ohne den "Fix" passiert Folgendes:

$ tsc -b tsconfig.dev.json
node_modules/@types/jsdom/index.d.ts:28:40 - error TS2304: Cannot find name 'DocumentFragment'.

28         static fragment(html: string): DocumentFragment;
                                          ~~~~~~~~~~~~~~~~

node_modules/@types/jsdom/index.d.ts:45:28 - error TS2304: Cannot find name 'Node'.

45         nodeLocation(node: Node): ElementLocation | null;
                              ~~~~

node_modules/@types/jsdom/index.d.ts:188:19 - error TS2304: Cannot find name 'HTMLScriptElement'.

188         element?: HTMLScriptElement | HTMLLinkElement | HTMLIFrameElement | HTMLImageElement;
                      ~~~~~~~~~~~~~~~~~

node_modules/@types/jsdom/index.d.ts:188:39 - error TS2304: Cannot find name 'HTMLLinkElement'.

188         element?: HTMLScriptElement | HTMLLinkElement | HTMLIFrameElement | HTMLImageElement;
                                          ~~~~~~~~~~~~~~~
<snip - numerous other errors>

1. Die jest Tests erfordern testEnvironment: 'jsdom' im Gegensatz zu 'node' .

Ohne den "Fix" passiert Folgendes:

$ jest --runInBand plugins/maven
 FAIL  plugins/maven/__tests__/maven.test.ts
  maven
    updatePomVersion
      ✕ should replace the previousVersion with the newVersion (39ms)

  ● maven › updatePomVersion › should replace the previousVersion with the newVersion

    ReferenceError: XPathEvaluator is not defined

      51 | ) => {
      52 |   const pomDom = new jsdom.JSDOM(content, {contentType: "text/xml"}).window.document;
    > 53 |   const evaluator = new XPathEvaluator();
         |                     ^
      54 |   const resolver = evaluator.createNSResolver(pomDom.documentElement);
      55 |   const expression = evaluator.createExpression("/project/version", resolver);
      56 |   const versionNode = expression.evaluate(pomDom.documentElement, XPathResult.FIRST_ORDERED_NODE_TYPE);

      at Object.exports.updatePomVersion (plugins/maven/src/index.ts:53:21)
      at Object.test (plugins/maven/__tests__/maven.test.ts:53:26)

Keine der oben genannten "Fixes" funktioniert, wenn sie in den Root-Konfigurationen des Plugins festgelegt ist, zB weder plugins/maven/tsconfig.json noch eine jest Konfiguration in plugins/maven/package.json . Das Vornehmen der Änderungen an den Root-Konfigurationsdateien schien die Tests oder die Funktionalität nicht negativ zu beeinflussen.

ist das in deiner Filiale? Ich kann das wahrscheinlich beheben

Noch nicht... Ich stelle sicher, dass alle Tests (und neue) bestehen, bevor ich drücke. Ich werde Sie anpingen, wenn sie zur Überprüfung bereit sind.

Ich habe gerade den Master auf meinen Zweig umbasiert, und jetzt erhalte ich mehrere Build-Fehler.

Zuerst wurde die Datei yarn.lock wegen eines Merge-Konflikts gesperrt, also musste ich sie löschen und neu erstellen:

error Incorrect integrity when fetching from the cache for "babel-plugin-jest-hoist". Cache has "sha512-u+/W+WAjMlvoocYGTwthAiQSxDcJAyHpQ6oWlHdFZaaN+Rlk8Q7iiwDPg2lN/FyJtAYnKjFxbn7xus4HCFkg5g== sha1-EpyAulx/x1uvOkW5Pi43LVfKJnc=" and remote has "sha512-+AuoehOrjt9irZL7DOt2+4ZaTM6dlu1s5TTS46JBa0/qem4dy7VNW3tMb96qeEqcIh20LD73TVNtmVEeymTG7w==". Run `yarn cache clean` to fix the problem

Sobald ich das getan habe, erhalte ich jetzt @octokit/graphql Fehler:

$ tsc -b tsconfig.dev.json
packages/core/src/auto.ts:2018:13 - error TS2571: Object is of type 'unknown'.

2018         if (result?.[`hash_${commit}`]) {
                 ~~~~~~

packages/core/src/auto.ts:2019:27 - error TS2571: Object is of type 'unknown'.

2019           const number = (result[`hash_${commit}`] as ISearchResult).edges[0]
                               ~~~~~~

packages/core/src/release.ts:286:52 - error TS2769: No overload matches this call.
  Overload 1 of 2, '(o: ArrayLike<unknown> | { [s: string]: unknown; }): [string, unknown][]', gave the following error.
    Argument of type 'unknown' is not assignable to parameter of type 'ArrayLike<unknown> | { [s: string]: unknown; }'.
      Type 'unknown' is not assignable to type '{ [s: string]: unknown; }'.
  Overload 2 of 2, '(o: {}): [string, any][]', gave the following error.
    Argument of type 'unknown' is not assignable to parameter of type '{}'.

286       (acc, result) => [...acc, ...(Object.entries(result) as QueryEntry[])],
                                                       ~~~~~~


packages/core/src/__tests__/git.test.ts:209:12 - error TS2571: Object is of type 'unknown'.

209     expect(result!.data).not.toBeUndefined();
               ~~~~~~~


Found 4 errors.

error Command failed with exit code 2.

Ich hatte große Hoffnung, dass ich dafür eine PR erstellen könnte - aber ich befürchte, es ist noch nicht fertig.

Okay, ich habe herausgefunden, was ich tun musste - ich habe gerade die yarn.lock Datei von master und dann yarn clean && yarn install && yarn build && yarn test plugins/maven und ich denke, ich bin gut damit -gehen.

Fantastisch! Ich werde das heute überprüfen. Entschuldigung, dass ich am Wochenende nicht geantwortet habe!

:rocket: Ausgabe wurde in v9.40.0 :rocket: