Skip to content

Latest commit

 

History

History
118 lines (98 loc) · 3.03 KB

File metadata and controls

118 lines (98 loc) · 3.03 KB

🔧 Release Workflow Fix

🚨 Problem identifiziert

Symptome:

Commit message: Merge pull request #9 from securebitsorg/feature/github-releases-documentation
Current version: 1.9.1
Last tag version: 0.0.0  ← Problem!
Should release: false     ← Problem!
Release type: 
New version: 

Root Cause:

  1. Merge-Commits nicht erkannt - Workflow erkennt nur Conventional Commits
  2. Tag-Erkennung fehlerhaft - git describe --tags --abbrev=0 gibt "0.0.0" zurück
  3. Versionssynchronisation - Lokale Dateien vs. Remote Tags inkonsistent

✅ Implementierte Lösung

1. Merge-Commit-Unterstützung

# Behandle Merge-Commits speziell
if [[ "$COMMIT_MSG" =~ ^Merge[[:space:]]pull[[:space:]]request ]]; then
  echo "Merge commit detected, analyzing PR content..."
  # Für Merge-Commits: Minor release (neue Features zusammengeführt)
  SHOULD_RELEASE="true"
  RELEASE_TYPE="minor"
  NEW_VERSION=$(echo $CURRENT_VERSION | awk -F. '{print $1"."$2+1".0"}')

2. Versionssynchronisation

Vor dem Fix:

  • VERSION: 1.9.1
  • version.py: 1.9.1
  • pyproject.toml: 1.9.1
  • Git Tag: v1.10.0 ← Inkonsistenz!

Nach dem Fix:

  • VERSION: 1.10.0 ✓
  • version.py: 1.10.0 ✓
  • pyproject.toml: 1.10.0 ✓
  • Git Tag: v1.10.0 ✓

3. Verbesserte Tag-Erkennung

# Robustere Tag-Erkennung
LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0")
LAST_TAG_VERSION=${LAST_TAG#v}
echo "Last tag version: $LAST_TAG_VERSION"

🎯 Release-Trigger-Patterns

Automatische Releases:

  1. Merge PR: Merge pull request #X → Minor Release
  2. Feature: feat: neue funktion → Minor Release
  3. Fix: fix: bugfix → Patch Release
  4. Breaking: feat!: breaking change → Major Release
  5. Manual: [release] in Commit-Message → Patch Release

Beispiel-Workflow:

# 1. Feature-Branch entwickeln
git checkout -b feature/neue-funktion
git commit -m "feat: neue coole funktion"
git push origin feature/neue-funktion

# 2. Pull Request erstellen und mergen
# → Automatisch: v1.10.0 → v1.11.0 (Minor)

# 3. Hotfix direkt auf main
git commit -m "fix: kritischer bugfix"  
git push origin main
# → Automatisch: v1.11.0 → v1.11.1 (Patch)

🧪 Testing

Nächster Test:

  1. Merge diesen PR
  2. Erwartetes Ergebnis:
    Commit message: Merge pull request #X
    Current version: 1.10.0
    Last tag version: 1.10.0
    Should release: true
    Release type: minor  
    New version: 1.11.0
    

📋 Zukünftige Verbesserungen

Option 1: Semantic Release Integration

- uses: cycjimmy/semantic-release-action@v3
  with:
    semantic_version: 19
    branches: |
      [
        'main'
      ]

Option 2: Automatische Version-Sync

- name: Sync version files
  run: |
    NEW_VERSION=${{ steps.release.outputs.new_version }}
    echo "$NEW_VERSION" > VERSION
    sed -i "s/__version__ = \".*\"/__version__ = \"$NEW_VERSION\"/" __version__.py
    sed -i "s/version = \".*\"/version = \"$NEW_VERSION\"/" pyproject.toml

Problem behoben in v1.10.1 🚀