Automatische Pull Requests erstellen

[kurmann]

autolabeler:
  - label: 'chore'
    files:
      - '*.md'
    branch:
      - '/docs{0,1}\/.+/'
  - label: 'bug'
    branch:
      - '/fix\/.+/'
    title:
      - '/fix/i'
  - label: 'enhancement'
    branch:
      - '/feature\/.+/'
    body:
      - '/JIRA-[0-9]{1,4}/'

Quelle: https://github.com/release-drafter/release-drafter?tab=readme-ov-file#autolabeler

[kurmann]

Frage: Die Funktion greift aber nur wenn ich Pull Requests automatisch durch den Release Drafter erstellen lasse?

---

Die Autolabeler-Funktionalität des Release Drafters wird tatsächlich nur ausgeführt, wenn der Release Drafter aktiv ist und einen Entwurf für die Release Notes erstellt oder aktualisiert. Sie ist nicht dazu gedacht, Labels auf Pull Requests anzuwenden, unabhängig vom Release Drafter.

Für die automatische Labelzuweisung bei der Erstellung oder Aktualisierung von Pull Requests gibt es jedoch eine GitHub Action namens "labeler" oder ähnlich, die Labels basierend auf bestimmten Regeln anwendet. Diese Action ist unabhängig von Release Drafter und kann für jeden Pull Request ausgelöst werden, nicht nur für solche, die von Release Drafter behandelt werden.

Hier ist ein Beispiel für eine GitHub-Action, die den "labeler" verwendet:

name: PR Labeler

on:
  pull_request_target:
    types: [opened, edited, synchronize, reopened]

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v3
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"

Sie müssten eine Konfigurationsdatei für diese Action namens labeler.yml in Ihrem .github-Verzeichnis erstellen, in der Sie die Regeln für das Labeling festlegen:

# Beispiel für eine `labeler.yml`
enhancement:
  - '**/feature/**/*'
bug:
  - '**/bug/**/*'
documentation:
  - '**/docs/**/*'

Mit dieser Konfiguration würde die Action das Label enhancement auf Pull Requests anwenden, deren Branch-Pfade feature enthalten, bug für Pfade mit bug und documentation für Pfade mit docs.

Der oben genannte Workflow und die labeler.yml Datei sollten im Hauptzweig Ihres Repositories platziert werden.

[kurmann]

Ist in Ordnung. Dann möchte ich aber diese Funktion in einen separaten Workflow aufnehmen, der bei jedem Push eines Branches der nicht Main ist, ausgeführt wird und einen Pull Request mit passendem Titel und den übernommen Labels der zugehörigen Issues erstellt.

Ich spreche von einem Pull Request-Entwurf.

Offene Pull Requests sollen aktualisiert werden.

---

Um eine GitHub Action zu erstellen, die bei jedem Push zu einem Nicht-Main-Branch einen Pull Request-Entwurf erstellt und die Labels von verknüpften Issues übernimmt, können Sie einen Workflow wie folgt einrichten:

name: Automatischer Pull Request-Entwurf

on:
  push:
    branches:
      - '**'
      - '!main'
      - '!master'

jobs:
  create-pull-request:
    runs-on: ubuntu-latest
    if: github.ref != 'refs/heads/main' && github.ref != 'refs/heads/master'
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      # Optional: Fügen Sie Schritte hinzu, um Änderungen zu bauen/testen

      - name: Erstelle Pull Request-Entwurf
        uses: peter-evans/create-pull-request@v3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          commit-message: 'Automatischer Pull Request-Entwurf'
          title: 'Automatischer Pull Request-Entwurf für ${{ github.ref }}'
          body: |
            Automatischer Pull Request-Entwurf für Änderungen im Branch `${{ github.ref }}`.
          labels: |
            autolabel
          draft: true

In diesem Workflow:

• Der Trigger on: push sorgt dafür, dass der Workflow für jeden Branch außer main und master ausgelöst wird.
• Der if-Ausdruck verhindert, dass der Workflow für die main- und master-Branches ausgeführt wird.
• Der create-pull-request Job verwendet die Action peter-evans/create-pull-request, um einen Pull Request-Entwurf zu erstellen. Diese Action bietet eine Vielzahl von Optionen, die Sie für Ihren Use-Case anpassen können.
• Das Label autolabel wird dem Pull Request automatisch hinzugefügt. Sie müssten einen separaten Prozess oder Workflow haben, um die richtigen Labels von verknüpften Issues zu übernehmen, da dies nicht automatisch passiert.

Beachten Sie, dass es momentan keine standardmäßige GitHub Action gibt, die Labels von Issues direkt auf Pull Requests überträgt. Labels müssen entweder manuell zugewiesen werden, oder Sie müssen eine benutzerdefinierte GitHub Action schreiben, die die GitHub API verwendet, um verbundene Issues zu durchsuchen und ihre Labels auf den Pull Request zu kopieren. Dies ist ein fortgeschrittener Anwendungsfall, der eine detaillierte Logik erfordern würde, um zu bestimmen, welche Issues zum Pull Request gehören, und um entsprechende Labels korrekt anzuwenden.

[kurmann]

Das mit der Übername der Labels schein zu komplex zu sein. Dann lasse ich das Thema. Ich möchte nicht unnötig Komplexität hinzufügen.

---

Das ist absolut verständlich. Einfachheit in Automatisierungsprozessen kann oft effektiver sein und hilft, die Wartung zu vereinfachen und Fehler zu minimieren. Sie können immer noch viel Effizienz durch die Verwendung von GitHub Actions für Workflows gewinnen, die weniger Komplexität erfordern, wie das automatische Erstellen von Pull Request-Entwürfen und die Verwendung von Auto-Labeling basierend auf Branch-Namen oder anderen klaren Mustern.

Wenn Sie später entscheiden, dass Sie die Funktionalität brauchen und bereit sind, die zusätzliche Komplexität in Kauf zu nehmen, können Sie immer zurückkommen und die Funktionalität mit neuen Tools oder Services erweitern, die möglicherweise in der Zwischenzeit verfügbar geworden sind.

Für jetzt, wenn Sie Hilfe bei anderen Aspekten Ihrer Automatisierungsprozesse benötigen oder Fragen zu GitHub Actions oder Release Drafter haben, stehe ich gerne zur Verfügung!