Versionsübergabe funktioniert nicht

[kurmann]

[kurmann]

(...)

[kurmann]

Es funktioniert gar nichts. Hier steckt der Wurm drin. Wahrscheinlich zweckentfremden wir den Release Drafter und wir sollten die Versionierung gar nicht automatisieren.

Was wäre wenn ich Release-Branches erstellen würde wie "release/v0.3.0" und dann ein- oder mehrere Features oder Bugfixes auf den Release-Branch sammeln und der Release Crafter würde dann anhand den Pull Requests auf den Release den Release Draft erstellen sobald der Pull Request auf den Main erfolgt.

---

Die Verwendung von Release-Branches kann eine gute Methode sein, um Features und Bugfixes zu organisieren, bevor sie in den Hauptbranch (main) gemerged werden. Das würde Ihnen auch mehr Kontrolle darüber geben, wann und wie die Versionen erhöht werden. Hier ist eine mögliche Vorgehensweise, die Sie für Ihre Releases anwenden könnten:

1. Erstellen von Release-Branches: Für jede neue Version erstellen Sie einen neuen Release-Branch (zum Beispiel release/v0.3.0).

2. Sammeln von Änderungen: Auf diesem Branch sammeln Sie alle Features und Bugfixes. Jeder Pull Request, der zu diesem Branch gemacht wird, sollte alle erforderlichen Änderungen für das nächste Release enthalten.

3. Versionierung in Pull Requests: Wenn Sie Pull Requests für diesen Release-Branch erstellen, können Sie im Titel oder in den Beschreibungen des Pull Requests die Art der Änderungen angeben (zum Beispiel #minor oder #patch), um zu signalisieren, wie die Version angepasst werden sollte.

4. Erstellung des Release Drafts: Sobald Sie bereit sind, den Release zu veröffentlichen, erstellen Sie einen Pull Request, um den Release-Branch in den Hauptbranch zu mergen. Release Drafter kann dann basierend auf diesem Pull Request und den darin enthaltenen Änderungen einen Release Draft erstellen.

5. Tagging und Veröffentlichung: Nachdem der Pull Request gemerged wurde, können Sie manuell einen Git-Tag für die neue Version erstellen und den Release Draft veröffentlichen.

Das wäre eine manuellere Methode, aber sie gibt Ihnen mehr Kontrolle und ist weniger fehleranfällig, als zu versuchen, die Versionierung automatisch zu handhaben, vor allem, wenn die Automatisierung nicht wie erwartet funktioniert.

In Ihrem Fall könnten Sie den Release Drafter so konfigurieren, dass er auf Pull Requests auf den Hauptbranch reagiert und das Changelog basierend auf den Titeln und Beschreibungen der Merged Pull Requests erstellt. Hier ist ein einfaches Beispiel, wie der Workflow für den Release Drafter aussehen könnte:

name: Release Drafter

on:
  pull_request:
    types: [closed]
    branches:
      - main

jobs:
  update_release_draft:
    runs-on: ubuntu-latest
    if: github.event.pull_request.merged == true
    steps:
      - uses: actions/checkout@v2

      - name: Run Release Drafter
        uses: release-drafter/release-drafter@v5
        with:
          config-name: 'release-drafter-config.yml'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Diese Konfiguration würde den Release Drafter jedes Mal auslösen, wenn ein Pull Request in den Hauptbranch gemerged wird. Stellen Sie sicher, dass Sie eine entsprechende Konfigurationsdatei release-drafter-config.yml haben, die Ihren Anforderungen entspricht.

[kurmann]

Wird übernommen vom Workflow in

• 4