Auto: [RFC] Etikettenkonfiguration vereinfachen

Ich mag die erste Möglichkeit. es ist super einfach und sauber, ich habe Probleme den Unterschied zwischen none und skip . Wenn ich das richtig verstehe, hat skip keinen Einfluss auf das Changelog und muss mit einem Server-Label versehen sein, und none wird eine Veröffentlichung überspringen, aber einen einzigartigen Changelog-Eintrag erstellen.

diese Methode beseitigt die meisten Abkürzungen, aber ich denke, wir könnten noch ein paar unterstützen?

zum Beispiel würde Folgendes das Standardlabel major überschreiben, aber auch die Beschreibung und den changelogTitle erben

{
  labels: [
    {
      name: 'Breaking change',
      releaseType: 'major'
    }
  ]
}

oder einfach den Titel bearbeiten

{
  labels: [
    {
      releaseType: 'major',
      changelogTitle: 'Super Big Changes'
    }
  ]
}

skip ist keine Freigabe. none bedeutet, dass das Label keinen Einfluss auf die Veröffentlichung hat... es kann also veröffentlicht werden oder nicht, je nachdem, ob andere Labels vorhanden sind. Es braucht einen besseren Namen.

Also haben die Labels nach Ihrem Vorschlag Standard-Fallbacks basierend auf dem, was releaseType vorhanden ist? Ich denke, das macht Sinn.

Also haben die Labels nach Ihrem Vorschlag Standard-Fallbacks basierend auf dem vorhandenen releaseType? Ich denke, das macht Sinn.

ja

@zephraph Es braucht einen besseren Namen.

Ich denke, es ist ein großartiges. Es gibt nichts Besseres, als zu sagen "es ist keines, weil es keinen Einfluss auf den Veröffentlichungsprozess hat, zB lästige Pflichten/Abhängigkeiten/was auch immer".

finde das sinnvoll.

Ja, total.

Der Vorschlag ist toll.
Ich denke, dass name und chagelogTitle beide Standardwerte haben sollten, die auf releaseType basieren.

Ich habe jetzt eine PR dafür. Es geht nicht auf folgendes ein

1. Changelog-Titel können Labels hinzugefügt werden, aber es ist nicht genau klar, in welcher Reihenfolge sie Vorrang haben. Welcher Changelog-Titel hat Vorrang, wenn Neben- und Dokumentationslabels vorhanden sind?

2. Logic meisten der hier beschriebenen Validierungen sollten wahrscheinlich im Autobot leben. Ich denke nicht, dass Auto selbst dies erzwingen sollte

3. (bezogen auf 1) > Mehrere keine Labels können eingefügt werden, um die PR unter verschiedenen Abschnitten des Changelogs hinzuzufügen

Ich verstehe es nicht. Wie _"Ein Skip-Label ist nur gültig, wenn es mit einem Semver-Label gepaart ist und ist ansonsten ein No-Op."_ Sinn? Wenn ich deps Label oder infra , ist der Typ skip und ich möchte die Freigabe überspringen, warum muss ich auch ein Semver-Label hinzufügen? Ich schätze, ich sollte dann none , aber dies ermöglicht auch das Hinzufügen von Semver-Label, also... WAT?! :D

Aktuell habe ich

    "skipReleaseLabels": [
      "documentation",
      "skip-release",
      "devDeps",
      "infra"
    ],
    "labels": {
      "deps": {
        "name": "deps",
        "title": "🔩 Dependency Updates"
      },
      "devDeps": {
        "name": "devDeps",
        "title": "🔩 Dependency Updates"
      },
      "documentation": {
        "name": "documentation",
        "title": "🗒️ Documentation"
      },
      "core": {
        "name": "core",
        "title": "📦 Core"
      }
    },

und ich möchte auf docs, skip-release, devDeps und infra überspringen, aber zum Beispiel nicht auf deps überspringen. Weil ich renovate verwende und Patch-Releases auf fix(deps) möchte.

Ich habe auch onlyPublishWithReleaseLabel sowieso aktiviert, also wird es kein großes Problem für mich sein.

Und noch eine Sache, ist changelogTitle auf dem next Dist-Tag? Ich bitte nur um Klarstellung, weil es in der PR nicht gezeigt wird.

@tunnckoCore Ich denke, Ihr Setup würde auf die neue Weise so aussehen:

{
  "labels": [
    {
      "name": "deps",
      "title": "🔩 Dependency Updates",
      // when deps are merged create a patch release
      "releaseType": "patch"
    },
    {
      "name": "devDeps",
      "title": "🔩 Dependency Updates",
      "releaseType": "none"
    },
    {
      "name": "documentation",
      "title": "🗒️ Documentation",
      "releaseType": "none"
    },
    {
      "name": "core",
      "title": "📦 Core",
      "releaseType": "patch"
    }
  ]
}

Die None fungiert effektiv als skip . Aber wenn Sie wirklich ein devDep Update veröffentlichen müssten, könnten Sie patch hinzufügen und eine Veröffentlichung würde erfolgen. Dies unterscheidet sich vom Hinzufügen eines skip Labels, das die Veröffentlichung unabhängig von anderen Labels überspringen würde.

ÄnderungsprotokollTitel

Dies habe ich auch nicht getan. Es ist immer noch nur der Titel. Ich werde dies zu meiner PR für den Refactor hinzufügen (immer noch nicht beim nächsten. Ich werde es nach changelogTitle rausbringen)

Richtig. OK großartig :)

Problem wurde in v8.0.0-next.8 veröffentlicht

Ist es jetzt? Ich vermute, dass prerelease s auf next ? :denken: Wie auch immer, ich bin nicht in Eile. Kämpfe immer noch mit Yarn v2+pnp und dem Aufbauen/Bündeln.

edit: Und bedeutet das Fehlen von title/changelogTitle immer noch, dass es keinen Abschnitt in den Versionshinweisen gibt?

@tunnckoCore Es gibt

Ich frage nach den anderen "benutzerdefinierten Labels", die wir aus der Konfiguration hinzufügen und bei denen es nicht um den Server geht. Wenn ich das Label infra ohne Titel habe, wird es nicht hinzugefügt, oder? Und wenn ich einen Titel habe (wie in devDeps), wird er hinzugefügt.

:rocket: Ausgabe wurde in v8.0.0 veröffentlicht :rocket:

@adierkens , es sieht so aus, als ob dieses Problem der Hauptanstoß für die große Version von v8 war, also stelle ich diese Frage hier ... Muss ich etwas Besonderes tun, um von v7.x auf v8 zu aktualisieren?

Wenn Sie zusätzliche labels oder skipReleaseLabels Sie das neue Format verwenden

https://intuit.github.io/auto/pages/autorc.html#label -Anpassung

Wooohooo! :tada: Ich werde es am Wochenende versuchen.

Zuallererst coole Änderungen für v8!

Hinsichtlich

Changelog-Titel können Labels hinzugefügt werden, aber es ist nicht genau klar, in welcher Reihenfolge sie Vorrang haben. Welcher Changelog-Titel hat Vorrang, wenn Neben- und Dokumentationslabels vorhanden sind?

Aus lokalen Tests scheint das aktuelle Verhalten wie folgt zu sein:

• Ordnen Sie eine gegebene PR dem ersten Label mit wahrheitsgetreuem changelogTitle in der Prioritätsreihenfolge von releaseType ( major , minor , patch , dann alle anderen)
• Wenn der PR mehrere Labels hat, die derselben Priorität von releaseType , wird PR zuerst in den Abschnitt des Labels aufgenommen, das in der Konfiguration definiert wurde (Standardlabels gehen allen anderen voraus).

Nachfolgend einige Beispiele:

(1): kleinere und keine Labels
Konfiguration:

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "none" },
  { "name": "minor", "changelogTitle": "Enhancement", "releaseType": "minor" }
]

Labels auf PR:

minor

Änderungsprotokoll-Label-Abschnitt: minor

• weil minor releaseType eine höhere Priorität hat

(2): mehrere Patch-Etiketten
Konfiguration:

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "patch" },
  { "name": "core", "changelogTitle": "Core Change", "releaseType": "patch" }
]

Labels auf PR:

core

Änderungsprotokoll-Label-Abschnitt: typescript

• weil das Label typescript in der Konfiguration vor core

(3): keine Beschriftung und standardmäßig keine Beschriftung
Konfiguration:

"labels": [
  { "name": "typescript", "changelogTitle": "Typescript Change", "releaseType": "none" }
]

Labels auf PR:

internal

Änderungsprotokoll-Label-Abschnitt: internal

• weil das Label internal in der Konfiguration vor typescript erscheint (es erscheint in der Standardkonfiguration, die die höchste Priorität zwischen denselben releaseType

@hipstersmoothie , Ist das obige Verhalten / die oben genannte Rangfolge beabsichtigt?

Wenn ja, wäre es gut, die Dokumentation zu ergänzen, damit klar ist, wie die Änderungsprotokoll-Labelabschnitte generiert werden und wie Abschnitte Vorrang haben (ich könnte bei Bedarf dabei helfen).

Wenn nicht, können wir daran arbeiten, eine Rangfolge zu definieren, entweder als Teil dieser oder einer anderen Ausgabe?

Ich sehe es nicht als etwas Besonderes oder Falsches. Es scheint intuitiv genug. Das einzig Wichtige ist, dass major , minor und patch immer an erster Stelle im Changelog stehen, nur weil es so etwas wie Standard ist. Aber auch wenn die Reihenfolge konfigurierbar ist, ist es auch in Ordnung.