Auto: Mehrere Paketmanager-Plugins in einem Repository

Wenn ich etwas genauer darüber nachdenke, wäre es wahrscheinlich sinnvoller, eine neue Konfigurationsoption auf oberster Ebene einzuführen.

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

Um dies zu erreichen, könnten wir Iteratorfunktionen verwenden, um shipit für mehrere Dinge auszuführen und die gleiche Anzahl von Commits zu generieren

ex für neueste:

1. laufen alle gleichzeitig
2. Yield vor dem Commit des Changelogs
3. Changelog auf einmal begehen
4. Ausbeute bis Version gestoßen
5. Commit-Version, falls erforderlich
6. bis zum Ende laufen

Mit diesem Setup könnten Sie wirklich alle zusammen auf lerna verzichten

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

Wenn einem package keine Commits zugeordnet werden, wird keine Freigabe vorgenommen. Dies ermöglicht ein unabhängiges Monorepo-Management auf viel einfachere Weise und ohne lerna . Wenn Sie ein Monorepo mit fester Version wünschen, ist der klassische Weg der richtige Weg.

Ein weiteres cooles Feature davon ist, dass Sie in Ihrem Repository zwei leran Projekte mit unterschiedlichen Versionsschemas haben können ( fixed und independent ).

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

Dies bedeutet, dass Sie das Chrome-Web-Store-Plugin das npm-Plugin in einem Repository verwenden können.

Ich gehe davon aus, dass Sie meinen, dass Sie beide im selben Projekt _nicht_ verwenden können?

Jedes Plugin führt derzeit Commits, Tags und Pushs durch. das würde viel lärm erzeugen. müsste diese Git-Aktionen wahrscheinlich in den Kern verschieben, damit es nur einmal passiert? obwohl Sie möglicherweise separate Commits für jedes Paket wünschen.

Es kann sinnvoll sein, einen hybriden Ansatz zu verfolgen. Vielleicht führt jedes Plugin einen Commit durch, aber wir pushen nur einmal?

Ich bin mir nicht wirklich sicher, wie Tags in der Welt funktionieren würden, in der jeder Ordner eine eigene verpackte Version ist. Erstellen Sie ein Tag für jede Version, die Sie erstellen? Machst du am Ende einen?

Wenn ich etwas genauer darüber nachdenke, wäre es wahrscheinlich sinnvoller, eine neue Konfigurationsoption auf oberster Ebene einzuführen.

Ich mag die Idee, die Release-Erfahrung pro Paket anpassen zu können. Kann definitiv einige Vorteile sehen, wenn man ein s3/gh-pages-Deployment für ein docs Paket im Vergleich zu Ihren Bibliothekspaketen verwalten kann.

Eine zu handhabende Sache ist die Aufnahme eines Pakets in mehr als 1 Release-Pipeline. Was passiert bei:

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

Wird das chrome-ext Paket sowohl für npm _und_ webstore ? Oder gewinnt die npm Veröffentlichung, weil sie zuerst deklariert wird?

Ich bin mir nicht wirklich sicher, wie Tags in der Welt funktionieren würden, in der jeder Ordner eine eigene verpackte Version ist. Erstellen Sie ein Tag für jede Version, die Sie erstellen? Machst du am Ende einen?

Ich denke, wir können dem Lerna-Verhalten entsprechen. nur viele Tags auf einem Commit. jedes Tag wird dann zu einem eigenen Release

Wird das chrome-ext-Paket sowohl in npm als auch im Webstore veröffentlicht? Oder gewinnt die npm-Version, weil sie zuerst deklariert wird?

In diesem Fall würde es ja versuchen, beides zu tun. Aber das ist nur eine schlechte Konfiguration. Sie könnten das als Funktion verwenden und sagen, ein Paket in zwei verschiedenen Registrierungen zu veröffentlichen (z. B.: npm- und github-Paketregistrierung).

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

Das klingt interessant... und kompliziert 😅

Ich bin im Allgemeinen 👍 mit der Konfiguration über den Versuch, bei der Erkennung übermäßig intelligent zu sein (weil dies auf unerwartete Weise ausfallen und schwer zu testen sein kann).

Ich denke, meine erste Frage ist, wie der Standardzustand davon aussieht. Wenn Sie nur ein npm Plugin haben, müssen Sie dann eine Konfiguration hinzufügen, bevor es funktioniert? Gleiche Frage bei den anderen.

Was die Git-Interaktion betrifft, so scheint es mir, dass Git-Interaktionen im Allgemeinen nur ein Teil der Plugin-Pipeline sein sollten. Wenn ein Plugin einen Commit ausführen muss, sollte es nur in der Lage sein, einen commitfähigen Hook anzuzapfen. Pushing sollte jedoch wahrscheinlich nur im Kern gehandhabt werden, da es Auswirkungen auf Dinge wie die Ausführung von CI hat.

Wenn Sie nur ein npm-Plugin haben, müssen Sie die Konfiguration hinzufügen, bevor es funktioniert?

Eine Konfiguration, die heute funktioniert, sollte in der packages Welt funktionieren. Es sind also keine Änderungen erforderlich. Die meisten der Breaking Changes wären auf der Knoten-API-Seite und für normale Benutzer nicht sichtbar.

Wenn ein Plugin einen Commit ausführen muss, sollte es nur in der Lage sein, einen commitfähigen Hook anzuzapfen.

Ich mag diese Idee. Es ist wahrscheinlich nützlich, diese Git-Interaktion innerhalb von auto zu formalisieren. Und wenn sie diesen Hook nicht verwenden, bedeutet dies nur ein wenig mehr Lärm (z. B. ein zusätzlicher Commit und ein zusätzlicher Push)

Ich habe auch darüber nachgedacht, wie Sie Auto mit einem Monorepo verwenden können, und habe einen etwas anderen Ansatz entwickelt, der möglicherweise für Ihre Anforderungen geeignet ist.

Grundsätzlich können Sie, wenn Sie ein Monorepo haben, mehrere Unterverzeichnisse haben, die jeweils ihre eigene .autorc Datei haben, die alle Plugins einrichten kann, die jedes Unterprojekt benötigt.

Sie können dann für jedes Projekt ein anderes Präfix wählen, sodass jedes Projekt bei Bedarf zu unterschiedlichen Zeiten freigegeben werden kann. Zum Beispiel könnte eine Version von Unterprojekt1 mit sub-project/v1.4.5 getaggt werden und ein anderes Projekt würde das Tag sub-project2/v9.9.9

Auto kann dann etwas wie git describe --tags --matches "sub-project1/*" , um Tags für jedes Projekt entsprechend abzurufen und zu aktualisieren.

Nur ein Gedanke.

Das ist eigentlich ziemlich nah an dem Ansatz, den ich gewählt habe. Ich habe
habe diese Woche daran gearbeitet.

Ich musste dieses Flag zu einigen der bisherigen Befehle hinzufügen (—matches) und
es lief ziemlich reibungslos.

Ich habe mich für den Feldansatz „Pakete“ entschieden und es ist im Grunde nur und
Array von „autorc“s

Um das Präfix zu erhalten, habe ich einen Hook für Plugins hinzugefügt, um einen Namen bereitzustellen. Dies
hilft auch, automatisch zu signalisieren, wenn das Plugin mit mehreren Paketen kompatibel ist

Am Mi, 29. Januar 2020 um 21:11 Alejandro Barrientos <
[email protected]> schrieb:

Ich habe auch überlegt, wie man Auto mit einem Monorepo verwendet und kam auf
ein etwas anderer Ansatz, der für Ihre Bedürfnisse geeignet sein kann.

Grundsätzlich können Sie, wenn Sie ein Monorepo haben, mehrere Unterverzeichnisse haben
dass jeder seine eigene .autorc-Datei hat, die beliebige Plugins einrichten kann
jedes Unterprojekt benötigen würde.

Sie können dann für jedes Projekt ein anderes Präfix wählen, damit
jedes Projekt kann bei Bedarf zu unterschiedlichen Zeitpunkten freigegeben werden. Zum Beispiel a
Veröffentlichung von Unterprojekt1 könnte mit Unterprojekt/v1.4.5 getaggt werden und
ein anderes Projekt würde das Tag sub-project2/v9.9.9 bekommen

Auto kann dann etwas wie git describe --tags --matches . verwenden
"sub-project1/*", um Tags für jedes Projekt entsprechend abzurufen und zu aktualisieren.

Nur ein Gedanke.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/intuit/auto/issues/917?email_source=notifications&email_token=AAJDEBGUZR5HF6P3OKRILTDRAJOOXA5CNFSM4KMLWYF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTWP800
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

Wenn ich zurückkehre und das nochmal durchlese, bin ich eigentlich ziemlich aufgeregt! Die mehreren Tags mit dem Präfix des Paketnamens klingen wirklich gut. Außerdem gefällt mir das Feld packages .

@hipstersmoothie gibt es heute eine einfache Möglichkeit, mit shipit in 2 npm-Registrys zu veröffentlichen, die Sie gesehen haben? oder einige Funktionsumschaltungen in Auto, über die ich gerade keinen guten Überblick habe.

@vincentbriglia würde ein Plugin funktionieren, das im GitHub-Paket veröffentlicht? es könnte ziemlich viel vom npm-Plugin abhängen. Es wäre einfach für next und latest freizulassen, Kanarienvögel machen nicht so viel Sinn. Die Gedanken?

@hipstersmoothie Wir haben einen Fall, in dem wir dasselbe Paket in der NPM-Registrierung und der GHPR-Registrierung veröffentlichen. Der Grund dafür ist, dass das GHPR, obwohl es als solches angekündigt wird, Pakete nicht korrekt weiterleitet. Das zugrunde liegende Problem ist, dass wir auf npm und github den gleichen Umfang haben.

Wir entwickeln hauptsächlich hinter verschlossenen Türen, wir verwenden die Canary-Builds, um Gespräche/Genehmigungen mit unserem Designteam ab feature branches > next sodass Canary-Builds für uns in diesem Zusammenhang immer noch nützlich sind. Das npm-Plugin bietet derzeit diese Funktionalität, daher wäre es eine Schande, sie zu verlieren.

Ich nehme an, der Kontext bei der Verwendung von GHPR ist im Allgemeinen, dass es der primäre Ort ist, an dem im privaten "Organisations"-Kontext veröffentlicht wird, und wenn eine Komponente veröffentlicht werden soll, ist npmjs.org sekundär. (Ich habe niemanden gesehen, der öffentliche Komponenten von github installiert hat). Im Open-Source-Kontext handelt es sich im Allgemeinen um npmjs, kein GHPR oder eine andere private Paketregistrierung.

Nebenbei bemerkt, da Sie ein bestimmtes GHPR-Plugin erwähnen: Wir haben uns für nächste Woche etwas Zeit genommen, um ein automatisches Plugin zu erstellen, das Paketversionen basierend auf einigen Regeln entfernt (Organisationen sind auf 50 GB an Paketen beschränkt, und dazu gehört auch Docker Bilder)

• letzten Kanarienvogel in Reichweite entfernen
• Entferne den n-letzten Nächsten im Bereich
• ...

Ich würde auch gerne mit Ihnen warten, um einen bestimmten ghpr-Publisher zu erstellen, bis die Arbeiten an v10 beginnen, die hier vorgestellten Ideen scheinen sehr spannend und sind vielleicht "zukunftssicherer".

wir könnten vorerst ohne gleichzeitige Veröffentlichung öffentlich und privat leben, aber zumindest, damit Sie wissen, dass dies der Anwendungsfall von mir ist.

Ich dachte eher an ein "Sekundärpaket-Registrierungs"-Plugin. Das npm-Plugin würde also so funktionieren, wie es funktioniert, und es in jeder beliebigen Registrierung veröffentlichen, die konfiguriert ist. Dann würde dieses neue Plugin in einer zweiten Registry veröffentlichen (ob npm oder ghpr spielt keine Rolle), die alle Versionen freigibt, die sich auf dem HEAD-Commit befinden.

Nebenbei bemerkt, da Sie ein bestimmtes GHPR-Plugin erwähnen: Wir haben uns für nächste Woche etwas Zeit genommen, um ein automatisches Plugin zu erstellen, das Paketversionen basierend auf einigen Regeln entfernt (Organisationen sind auf 50 GB an Paketen beschränkt, und dazu gehört auch Docker Bilder)

Dies scheint eine gute Funktion zu sein. Ich wusste nicht, dass es diese Grenzen gibt!

Dieses neue Plugin würde in einer zweiten Registry veröffentlichen (ob npm oder ghpr spielt keine Rolle) und veröffentlicht alle Versionen, die sich auf dem HEAD-Commit befinden

naja das würde bestimmt funktionieren! edit: auch für unser(e) Szenario(s)

Hi! Wie ist der aktuelle Stand von Auto in Bezug auf diesen Thread? Ist es möglich, mehr als eine Sache aus derselben Veröffentlichung zu veröffentlichen?

da jedes Paketmanager-Plugin auf eine zusätzliche Datei für den Paketmanager angewiesen ist (alle außer git-tag )

Ich denke, das ist eine falsche Annahme. Ist das docker Plugin von einer Datei abhängig? Es könnte dafür unnötig sein, also ist es vielleicht ein schlechtes Beispiel. Hier ist dann noch einer: Ich interessiere mich für die Verwendung von Auto mit sbt (dem gängigsten Build-Tool für Scala) und es hat keine maschinenlesbare JSON/XML-Konfiguration. Ein sbt-Build wird mit Scala-Code konfiguriert und um alle Informationen über den Build zu extrahieren, müssen Sie auf irgendeine Weise mit sbt kommunizieren.

Dies ermöglicht ein unabhängiges Monorepo-Management auf viel einfachere Weise

Aus diesem Thread geht auch hervor, dass das Ziel darin besteht, Monorepo-Projekte mit mehreren Unterprojekten mit unterschiedlichen Veröffentlichungsanforderungen zu unterstützen. Wie wäre es mit einem einzelnen Projekt, das verschiedene Arten von Artefakten produziert? Zum Beispiel ein Docker-Image und ein Konfigurationsarchiv (um irgendwo hochgeladen zu werden). Oder eine GitHub-Aktion, die als Bibliothek auf NPM und als Aktion auf GitHub-Releases veröffentlicht werden kann.

Jedes Plugin führt derzeit Commits, Tags und Pushs durch. das würde viel lärm erzeugen. müsste diese Git-Aktionen wahrscheinlich in den Kern verschieben, damit es nur einmal passiert? obwohl Sie möglicherweise separate Commits für jedes package _wollen_ .

Ich denke, dies ist das Hauptproblem bei der aktuellen Implementierung von Plugins. Dies geht zurück auf meine Verwirrung über die Behauptung, dass jeder Befehl "nur eine Sache wirklich gut macht". Meiner Meinung nach sollte der publish Hook wirklich _nur veröffentlichen_ für den angegebenen Paketmanager, keine Commits erstellen oder Git-Tags pushen. Wenn sich jedes Publishing-Plugin nur auf die Implementierung seiner Paketmanager-Spezifika konzentrieren kann, können gemeinsame Teile des Prozesses wiederverwendet und/oder geteilt werden. Ist dies mit Auto noch möglich oder ist es zu voreingenommen auf die NPM-ähnlichen Projekte?